Control Stores execution order on a certain Action

[sergelerner]

Hi, I'm not sure how to exactly call it, but what I have is an Action to which few Stores subscribe, how would I control the order of Stores execution upon that Action? I think I'm looking for a way to chain Stores OnAction. If this is not possible, the minimum I need is to set the last Store that will act on a certain Action.

[amireitan]

+1

[BenGedi]

+1

[yonimor]

+1

[LongLiveCHIEF]

+1

Stay tuned. Maybe checkout my comment in #354

[sergelerner]

@LongLiveCHIEF In case I am misunderstood Id like to elaborate what I actually have in my application:

• I have few stores which listen to the following Actions: "add", "update" and "delete".
• Those Actions come from an external API, representing different entities in the application.
• I have a central Store called EntityStore which listens to "add" and acts like a database.
• EntityStore creates an EntityMap of all received entities by ID.
• Every time EntityStore updates it passes the EntityMap via trigger to the other Stores.
• Other Stores save a reference of EntityMap in case they need to fetch something from it.
• Other Stores onAdd create its own representation of the entity and passes its state to the View.
• Other Stores onUpdate do some business logic and update its entity representation.
• Other Stores onDelete delete its own representation of the entity.

Now since different Stores listen to the same Actions sometimes there is an execution order trouble.
Since I don't know how to control Stores Action execution order, the following idea came to place:

Basically Other Stores wont listen to the Actions "add", "update" and "delete". They will only listen to the EntityStore trigger, which will propagate in its payload the Action name, its original payload plus the EntityMap.

[LongLiveCHIEF]

Thanks for the excellent use-case... this will definitely help me inform the public api of this feature as I continue to work out the concept code for the 0.3 branch. Let me think through this later tonight, and I'll post an update with some psuedo-code that would be based on utilizing some POC code for reflux I'm working out. You can look at the implementation concept and give me some feedback.

[sergelerner]

in case this is going away, id love to get any input on my suggested workaround.

[LongLiveCHIEF]

Sorry, been taking a mid-week vacation. :-)

I wouldn't really call it a workaround, as much as a redesign. It's actually very close to the concept we have for how things will work in 0.3.0. We're adding a context concept with the 0.3 branch. You can attach both stores and actions to contexts, and contexts can be nested.

One of the roles of the contexts witll be to merge schemas of the stores inside the context, so that your components or other pieces of your app can declare the data they want, or the queries they want to run, directly from a context.

The image I'm sharing below is concept only. Some words for things might not be the best words either, but I think it's enough to provide the feedback you desire.

[sergelerner]

Thanks for sharing! Looks interesting. I can't say I understand everything, but if the general direction is aggregation and sharing - then it sound good. I will go with my solution for now. I hope it will be easy to migrate to 0.3.0 later on.

[sergelerner]

@H3Chief so I hear Reflux 3.0 is out : ) I am catching up.. is there a way to control Store execution on Actions or something similar ?