Skip to content
This repository has been archived by the owner on Mar 23, 2023. It is now read-only.

Why is it not possible to "dispatch in the middle of a dispatch" #47

Closed
mosch opened this issue Sep 5, 2014 · 5 comments
Closed

Why is it not possible to "dispatch in the middle of a dispatch" #47

mosch opened this issue Sep 5, 2014 · 5 comments

Comments

@mosch
Copy link

mosch commented Sep 5, 2014

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?

@sterpe
Copy link

sterpe commented Sep 5, 2014

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.

https://www.npmjs.org/package/quantum-flux

@fisherwebdev
Copy link
Contributor

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 isDispatching() method that you could utilize in your action queue.

@fisherwebdev
Copy link
Contributor

@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.

@mosch
Copy link
Author

mosch commented Sep 8, 2014

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.

ghing added a commit to ghing/learning-collaborative-maps that referenced this issue Jun 2, 2016
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
@achobanov
Copy link

@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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants