title: What if two Flux stores have to depend on each other
body: <p>One of the goals of Flux is to make the app more predictable by reducing crazy tangled dependencies. Using the Dispatcher you can define a strict order in which the Stores are updated. That creates a nice tree dependency hierarchy. That's the theory. Consider following situation:</p>
  
  <p>I have a game. The store sitting at the top of the hierarchy is <strong>StateStore</strong> that holds only the current game state, i. e. <em>playing</em>, <em>paused</em>, <em>over</em>. It is updated via actions like <strong>PAUSE</strong> or <strong>RESUME</strong>. All other stores depend on this one. So when a store handles some kind of update action (i. e. <strong>MOVE_LEFT</strong>), it first checks the StateStore and if the game is <em>paused</em> or <em>over</em>, it ignores the action.</p>
  
  <p>Now let's say that there is an action that would cause game over. It updates some store and the store decides that the game shouldn't continue (<em>"the game character moves left and falls into a trap"</em>). So the state in the StateStore should change to <em>over</em>. How do I do that?</p>
  
  <p>Theoretically, it should go like this:</p>
  
  <ol>
  <li>The given store is updated first and reaches the point of game over</li>
  <li>The StateStore is updated afterwards (it <em>waitsFor</em> the other store), checks the other store and switches the state to <em>over</em>.</li>
  </ol>
  
  <p>Unfortunately, the other store needs to access the StateStore as well to check the current game state to see if it should be updated at all (i. e. the game is not paused). They clearly depend on each other.</p>
  
  <p>Possible solutions:</p>
  
  <ol>
  <li>Merge such stores into one store. That would probably cause my whole app to collapse into a single store which brings up the question whether Flux in this case is a good idea.</li>
  <li>Distinguish <em>update order</em> and <em>read-only</em> dependencies. All stores would be updated in a strict order, however they could read from each other arbitrarily. The StateStore would therefore for every action check all existing stores and if any of them indicated game over, it would change the state to <em>over</em>, effectively preventing all other stores from updating.</li>
  </ol>
  
  <p>What do you think?</p>