-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Why is it not possible to "dispatch in the middle of a dispatch" #47
Comments
Yeah, had the same concern, I wrote a pure async dispatcher (it's pretty beta) but supports recursive dispatching in the correct order, while ensuring that there are no browser redraws until all affected views have updated. You can check it out here, maybe it would work for you too. |
We enforce this to ensure that a single action has caused all of the relevant stores to update themselves before moving forward with the next round of updates. Flux was originally created to deal with derived data: dependencies between stores. So if Store A needs to get data from Store B, and both stores respond to an particular action, we need to make sure that both of these have updated before they can get updated again. Otherwise, we are getting into a race condition. Instead we enforce that the state of the all the stores remain in sync. The design of the application (and the cognitive overhead) becomes much simpler when you cannot invoke a new dispatch while another dispatch is still occurring. It also forces you to always work with the singular flow of actions -> dispatcher -> stores -> views. If you have data flowing through the stores and views in any other way, then you are not conforming to that singular data flow, and your application will get messy as it grows larger and more complex. An action queue would not be a bad solution if you have multiple async API calls coming back at the same time. We are actually working on an action queue on the other end -- the store end, after the dispatches have occurred -- to maintain an action history for the purpose of optimistic updates. However, the same concept could get implemented at the point of the dispatcher, to manage the situation you are describing. The important thing would be to ensure, however, that two dispatches were not happening at the same time. The dispatcher does expose a |
@sterpe quantum-flux looks like it has a lot of great ideas in it. I'll take a deeper look, but the docs are nicely written and very understandable. |
thanks for your replies! i'm excited to see the action queue at the stores - i'll have my own dispatching queue for now. thank you guys. |
Don't fire an action in a method that's eventually called as a result of an action. This isn't allowed by Flux. More details can be found at facebookarchive/flux#47. Closes #41
@fisherwebdev Thanks for your reply. Let's imagine I have multiple instances of the same component, which must fire an action inside componentDidMount. All of those components are rendered from an array of data objects ( simultaneously ). How should I implement this? I am using Alt, but their docs say they use your dispatcher, so I figured I should ask here as well. Thanks |
Is there any reason why the dispatcher can't handle a dispatch in the middle of a dispatch?
I can't be sure, that this will not happen. I have a lot of async API calls that will dispatch events simultaneously and i'm running into this error.
Am i doing s.th. wrong? Is there any reason why you should not have a queue in the dispatcher?
The text was updated successfully, but these errors were encountered: