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 dis

Answer 1

I'm not an expert in flux but an architecture doesn't enable you to do something that wasn't possible before, it gives your application a structure that is extensible and understandable.

Answer 2

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 3

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.

Answer 4

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