The Dispatcher in Flux Context

Imagine living in a small town or community where information and events of public interest events are disseminated via a “town crier.”

I grew up in one. One major and recurring event back then was the “community environmental sanitation.” The community governing council picked a Saturday in which all commercial activities were put on-hold until 10am, and all youths and able adults came out en masse to participate in a cleaning of their surroundings and a repair of the public facilities.

So when a future date for such an activity was decided by the council, the “town crier” DISPATCEHD the information thusly:

“People of XYZ town, the community council has…”


  1. The town crier is non-selective in dispatching this information; its a public broadcast.
  2. If you were a youth in this community, the information would mean something to you and you would likely take an action — say, mark your calendar.
  3. If you were a child like I was then, the information would mean nothing to you, so you would tend to ignore it and play on.
In Flux context, the “dispatcher” can be likened to the “town crier”.

In React-Flux, we can think about it this way:

  1. The community council is the view.
  2. The decision/information from the council is the action.
  3. The medium the community council uses to pass information(action) to the town crier is the action creator.
  4. The piece of information the town crier disseminates to community members is a structures representation of the action.
  5. The town crier is the dispatcher.
  6. And the community members can be likened to the stores.

Note that in the small town picture we’ve painted:

  1. The town crier broadcasts information within the geographic boundaries of the community. Similarly in Flux, the dispatcher exposes a register method and all functions passed to the dispatcher via this register method defines the bounds of the broadcast.
  2. To avoid misunderstanding, the information/action being broadcast would at minimum, be clear on:
a.) What information it is (Type) and
b.) Any other thing that needs to be known about it (payload)

Action in Flux

In Flux context (assuming JavaScript implementation), an action is just a JavaScript object literal (name value pairs) nothing more.

Similar to the town crier’s information, an action in Flux is “expected” to convey Type and Payload. Note that this “expectation” is not enforced in any way. However, it is advised that you ensure this expectation is met to avoid headaches that may arise when you use any flux-oriented library that may have some logic strongly dependent on this expectation.

All right, enough talk and imagery. Let’s build a simple dispatcher using JavaScript.

To begin, here are some object literals demonstrating sample action structures:

Let’s build our dispatcher:

A basic dispatcher implemented in JavaScript.

Now that we have a dispatcher, lets build a simple action creator for passing payloads to be dispatched as actions to the dispatcher.

A basic action creator implemented in JavaScript.

In this discussion we have managed to paint a basic picture and JavaScript implementation of the dispatcher in Flux.

Yes, we kept it basic, but it should give the clear understanding needed to dig further and dance the Flux dance in your next project.