1

After having built a few apps using (what I believe) to be a Flux architecture based off a framework I built, I wonder what it means when:

Mozilla says:

"The dispatcher dispatches actions to interested stores. Only one action can be processed at any one time."

Or Facebook says:

"We need the dispatcher to be able to invoke the callback for Store B, and finish that callback, before moving forward with Store A."

Why I'm confused is because Javascript's concurrency model only allows one thing to happen at once, and ensures the call stack of the current action is depleted before it moves on with the task Queue.

So we get for free what Facebook and Mozilla says their dispatchers give us. We can't avoid it. Why are we talking about it like it's anything special?

Well... another consideration is if your "action" does something asynchronous with a callback like:

  1. update state,
  2. fire off an XHR,
  3. update state with result.

Here your action can be broken in 2 parts and something can happen in between 2 and 3, thus violating the "one action at a time" principle.

That problem is solved by nothing more than terminology:

  1. Define Action A as the thing that updates state and sends XHR.
  2. result of XHR triggers Action B which updates state.

After all, Facebook has said "Actions may also come from other places, such as the server."

So with a little change in terminology we have no need for a dispatcher that does anything beyond dispatch an event to interested stores.

So what am I missing? Why must a dispatcher in Flux do anything more than dispatch?

Mark Bolusmjak
  • 23,606
  • 10
  • 74
  • 129
  • 1
    It doesn't refer to the concurrency model. but rather how the dispatcher works. when an action is dispatched, that action must complete before another action can be dispatched. basically, you can't and shouldn't dispatch another action in a handler. – frostymarvelous Aug 05 '15 at 17:38
  • I like your rhetorical question because I agree. It should not. Your code should handle dependent event chains explicitly. A simple event emitter would suffice rather than a queue + event emitter but they would have less propaganda to peddle then. – King Friday Feb 08 '16 at 23:12

1 Answers1

1

My answer is: the people who wrote those bits of documentation weren't clear in what they were talking about.

Even the top stackoverflow React answerer and React contributor says:

In my understanding, asynchronous actions that rely on Ajax, etc. shouldn't block the action from being dispatched to all subscribers.

You'll have a separate action for the user action, like TODO_UPDATE_TEXT in the TodoMVC example and one that gets called when the server returns, something like TODO_UPDATE_TEXT_COMPLETED (or maybe just something more generic like TODO_UPDATE_COMPLETED that contains a new copy of the latest attributes).

See: https://stackoverflow.com/a/23637463/131227

Community
  • 1
  • 1
Mark Bolusmjak
  • 23,606
  • 10
  • 74
  • 129