Table of Contents

Flux is an architecture that Facebook uses internally when working with React. It is not a framework or a library. It is simply a new kind of architecture that complements React and the concept of Unidirectional Data Flow.

That said, Facebook does provide a repo that includes a Dispatcher library. The dispatcher is a sort of global pub/sub handler that broadcasts payloads to registered callbacks.

A typical Flux architecture will leverage this Dispatcher library, along with NodeJS's EventEmitter module in order to set up an event system that helps manage an applications state.

Flux is probably better explained by explaining its individual components:

Stores - Containers for application state & logic that have callbacks registered to the dispatcher

Controller Views - React Components that grab the state from Stores and pass it down via props to child components.

Lets take a look at what this process looks like graphically:

How does the API relate to this?

When you are working with data that is coming from (or going to) the outside, I've found that using Actions to introduce the data into the Flux Flow, and subsequently Stores, is the most painless way to go about it.

The Dispatcher is basically the manager of this entire process. It is the central hub for your application. The dispatcher receives actions and dispatches the actions and data to registered callbacks.

So it's essentially pub/sub?

Not exactly. The dispatcher broadcasts the payload to ALL of its registered callbacks, and includes functionality that allows you to invoke the callbacks in a specific order, even waiting for updates before proceeding. There is only ever one dispatcher, and it acts as the central hub within your application.

In the above example, we create an instance of our Dispatcher and create a handleViewAction method. This abstraction is helpful if you are looking to distinguish between view triggered actions v.s. server/API triggered actions.

Free Node eBook

Build your first Node apps and learn server-side JavaScript.

📧

Thank you!

You have successfully joined the Scotchy super duper web dev awesome mailing list.

Our method calls the dispatch method, which will broadcast the action payload to all of its registered callbacks. This action can then be acted upon within Stores, and will result in a state update.

The diagram below illustrates this process:

Dependencies

One of the coolest parts of the provided Dispatcher module is the ability to define dependencies and marshall the callbacks on our Stores. So if one part of your application is dependent upon another part being updated first, in order to render properly, the Dispatcher's waitFor method will be mighty useful.

In order to utilize this feature, we need to store the return value of the Dispatcher's registration method on our Store as dispatcherIndex, as shown below:

In Flux, Stores manage application state for a particular domain within your application. From a high level, this basically means that per app section, stores manage the data, data retrieval methods and dispatcher callbacks.

The most important thing we did above is to extend our store with NodeJS's EventEmitter. This allows our stores to listen/broadcast events. This allows our Views/Components to update based upon those events. Because our Controller View listens to our Stores, leveraging this to emit change events will let our Controller View know that our application state has changed and its time to retrieve the state to keep things fresh.

We also registered a callback with our AppDispatcher using its register method. This means that our Store is now listening to AppDispatcher broadcasts. Our switch statement determines whether, for a given broadcast, if there are any relevant actions to take. If a relevant action is taken, a change event is emitted, and views that are listening for this event update their states.

Our public method getShoes is used by our Controller View to retrieve all of the shoes in our _shoes object and use that data in our components state. While this is a simple example, complicated logic can be put here instead of our views and helps keep things tidy.

Action Creators are collections of methods that are called within views (or anywhere else for that matter) to send actions to the Dispatcher. Actions are the actual payloads that are delivered via the dispatcher.

The way Facebook uses them, action type constants are used to define what action should take place, and are sent along with action data. Inside of registered callbacks, these actions can now be handled according to their action type, and methods can be called with action data as the arguments.

Above we use React's keyMirror library to, yup you guessed it, mirror our keys so that our value matches our key definition. Just by looking at this file, we can tell that our app loads shoes. The use of constants helps keep things organized, and helps give a high level view of what the app actually does.

In our example above, we created a method on our ShoeStoreActions object that calls our dispatcher with the data we provided. We can now import this actions file into our view or API, and call ShoeStoreActions.loadShoes(ourData) to send our payload to the Dispatcher, which will broadcast it. Then the ShoeStore will "hear" that event and call a method thats loads up some shoes!

Now that we have gone through each individual part of the Flux architecture, we should have a much better idea of how this architecture actually works. Remember our graphical representation of this process from before? Lets have a look at a bit more granular view of this, now that we understand the function of each part of the flow:

After reading this article, I hope that if you didn't "get" Facebook's Flux Architecture before, that now you can say you do. It wasn't until building something with it that I understood how complimentary to React.js it actually is.

After you use Flux the first time, writing React without Flux feels like DOM traversal without jQuery. You can absolutely do it, but it feels less elegant and structured.

If you want to use the Flux architecture, but you don't want to use React, check out Delorean, a Flux framework that you can use with Ractive.js or Flight. Another library worth looking at is Fluxxor, which takes a different approach to Flux architecture and provides a tighter coupling of Flux's components into a central Flux instance.

Again, I believe that to truly understand Flux, you actually have to use it, so stay tuned for the 4th and final installment of Learning React where we will be building a shopping cart with React.js and Flux Architecture!