React.js - flux vs global event bus

Question

What is the advantage of using Flux over a global event bus? I think the dispatcher is all that is needed:

1. component publishes 'user event' with data to the dispatcher
2. dispatcher executes handler of the subscribed store
3. handler publishes 'update event' with the store's updated properties
4. dispatcher executes handler of the subscribed component, and updates component state with the store's updated properties

What am I missing here that I can't do without Flux?

Answer 1

I think what others have said about application structure and the change event is important, but I should add this one thing:

The dispatcher's waitFor method is the biggest difference between registering the stores with a dispatcher vs. the stores listening to a global event bus. This method lets you manage which stores update before others. And that becomes vital when you want StoreB to look first at what StoreA did before it decides what to do.

You could think of the dispatcher as a global event bus with a waitFor method, and that would be somewhat accurate.

Answer 2

我不是一个流动的专家，但是一个架构不能让你做一些以前不可能的事情，它给你的应用程序一个可扩展和可理解的结构。

Answer 3

I believe it's all about code structure which is understandable even in large scale.

Supose you have appState which holds underlying data for components.

The components call action . Action is responsible for gather data from XHR or modify the incoming data from component and then it dispatch complete data to subscribed store.

Store is the only part of your code, which can modify your appState and it is basically the only thing, what it does. It takes data from action and store them to appState or removes some data from appState according to action.

Then you fire stateChanged event, which your component should listen to and will rerender.

So you have all action specific logic in actions. You handle appState only in stores. And that should help you keep your code understandable.

Flux pattern

My understanding of why is good idea to dispatch only complete data comes mainly from this article . And it is based on official Facebook Flux diagram

The advantages of this approach are:

• stores are simple and synchronous, does not contain decision logic, just handles given data
• there is no need to fire another action in store, which will break one-directional chain of Flux
• dispatcher is the single channel for all state changes, it knows what action with what data is processed, so its easier for debugging

Answer 4

You basically described flux, the only difference is:

4. stores emit a change event

And the component updating its state isn't part of flux, that's a common practice for integrating flux and react.

Flux just names each of these pieces and gives guidelines on what each piece's responsibility is.

It's essentially a main event emitter (dispatcher), the event types (actions), functions that emit an event on the dispatcher (action creators; the event body is a payload), and other event emitters that: keep state, listen to the dispatcher and emit change events (stores).

At least that's how it works in JS. The core principle is the unidirectional data flow. There are plenty of event emitters that are used for bidirectional communication.