React Flux: Store dependencies

Question

so I have recently playing with React and the Flux architecture.

Let's say there are 2 Stores A and B. A has a dependecy on B, because it needs some value from B. So everytime the dispatcher dispatches an action, first B.MethodOfB gets executed, then A.MethodOfA.

I am wondering what are the advantages of this architecture over registering A as a listener of B and just executing the A.MethodOfA everytime B emits a change event?

Btw: Think about a Flux implementation without the "switch case" of the example dispatcher from facebook!

Answer 1

In my opinion I think this dispatcher is somehow an anti-pattern.

In distributed architectures based on event sourcing OR CQRS, autonomous components do not have to depend on each others as they share a same event log.

It's not because you are on the same host (the browser/mobile device) that you can't apply these concepts. However having autonomous stores (no store dependencies) means that 2 stores on the same browser will probably have duplicate data as the same data may be needed by 2 different stores. This is a cost to pay but I think in the long term it has benefits as it removes the store dependencies. This means that you can refactor one store entirely without any impact on components that do not use that store.

In my case, I use such a pattern and create some kind of autonomous widgets. An autonomous widget is:

• A store that listen to an event stream
• A component
• A LESS file (maybe useless now because of React Styles?)

The advantage of this is that if there is a bug on a given widget, the bug almost never involve any other file than the 3 mentionned above ;)

The drawback is that stores that host the same data must also maintain it. On some events, many stores may have to do the same action on their local data.

I think this approach scales better to larger projects.

See my insights here: Om but in javascript

Answer 2

The problem with an evented approach is that you don't have a guarantee as to which handlers will handle a given event first. So in a very large, complex app, this can turn into a tangled web where you're not really sure what is happening when, which makes dependency management between stores very difficult.

The benefits of the callback-based dispatcher are twofold: the order in which stores update themselves is declared in the stores that need this ordering, and it is also guaranteed to work exactly as intended. And this is one of the primary purposes of Flux -- getting the state of an app to be predictable, consistent and stable.

In a very small app that is guaranteed to not grow or change over time, I can't argue with what you are suggesting. But small apps have a tendency to grow into large ones, eventually. This often happens before anyone realizes it's happening.

There are certainly other approaches to Flux. Quite a few different implementations have been created and they have different approaches to this problem. However, I'm not sure which of these experiments scale well. On the other hand, the dispatcher in Facebook's Flux repo and the approach described in the documentation has scaled to truly gigantic applications and is quite battle tested.