title: What does it mean for a Flux dispatcher to guarantee synchronous actions?
body: <p>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:</p>
  
  <p>Mozilla says:</p>
  
  <blockquote>
    <p>"The dispatcher dispatches actions to interested stores. <strong>Only one
    action can be processed at any one time</strong>."</p>
  </blockquote>
  
  <p>Or Facebook says:</p>
  
  <blockquote>
    <p>"We need the dispatcher to be able to invoke the callback for Store B,
    <strong>and finish that callback, before moving forward with Store A</strong>."</p>
  </blockquote>
  
  <p>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.</p>
  
  <p>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?</p>
  
  <p>Well... another consideration is if your "action" does something asynchronous with a callback like:</p>
  
  <ol>
  <li>update state, </li>
  <li>fire off an XHR,</li>
  <li>update state with result.</li>
  </ol>
  
  <p>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.</p>
  
  <p>That problem is solved by nothing more than terminology: </p>
  
  <ol>
  <li>Define Action A as the thing that updates state and sends XHR.</li>
  <li>result of XHR triggers Action B which updates state.</li>
  </ol>
  
  <p>After all, Facebook has said "Actions may also come from other places, such as the server."</p>
  
  <p>So with a little change in terminology we have no need for a dispatcher that does anything beyond dispatch an event to interested stores. </p>
  
  <p>So what am I missing? Why must a dispatcher in Flux do anything more than dispatch? </p>