如果两个Flux商店必须相互依赖怎么办？

Question

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:

I have a game. The store sitting at the top of the hierarchy is StateStore that holds only the current game state, ie playing , paused , over . It is updated via actions like PAUSE or RESUME . All other stores depend on this one. So when a store handles some kind of update action (ie MOVE_LEFT ), it first checks the StateStore and if the game is paused or over , it ignores the action.

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 ( "the game character moves left and falls into a trap" ). So the state in the StateStore should change to over . How do I do that?

Theoretically, it should go like this:

1. The given store is updated first and reaches the point of game over
2. The StateStore is updated afterwards (it waitsFor the other store), checks the other store and switches the state to over .

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 (ie the game is not paused). They clearly depend on each other.

Possible solutions:

1. 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.
2. Distinguish update order and read-only 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 over , effectively preventing all other stores from updating.

What do you think?

Answer 1

In Flux stores should be as independent from each other as possible and should not read from each other. The only way to change their state is through actions.

In your case, if some store decides that the game is over — you should update a StateStore from the ActionCreator. You can do it by calling a HaltGameActionCreator from the store or by dispatching a HALT_GAME action from ActionCreator that triggered the store change in the first place.

Answer 2

For those having the same issue, you can read here about the actual application I had this problem with and how I approached it. Long story short, I allowed all the stores to arbitrarily read from each other (the suggested solution no. 2).

Note that ES6 modules allow circular dependencies which simplifies the implementation.

Nevertheless, looking back I'm not sure if it was a right decision. If a piece of business logic inherently contains a circular dependency, we should not try to apply a solution that doesn't really support it just because somebody says so. Flux is only one pattern, there are many other ways how to structure the code. So perhaps I would recommend collapsing the whole logic into a single store and use one of the other ways to implement the store itself (eg standard OOP techniques).

I would also consider using redux with reselect instead of Flux. The problem with the original example is with the StateStore that depends on two different inputs. It can be changed either by the user explicitly pausing/resuming the game, or by the game situation reaching game over. The advantage of this approach is that you need to check only one store to get the current game state.

With redux/reselect, you'd have one reducer handling pause/resume actions and another reducer handling the game situation . Then you'd have a selector combining these two pieces of information into the final game state. Most of the business logic would be moved from the stores to action creators, ie, in the moveLeft() action creator, you'd use this selector to check the game state and only then you'd dispatch MOVE_LEFT action.

Note that this is just a rough idea and I don't know if it's viable.