Starting with Flux

We have been using Flux for months now and we are genuinely impressed with its predictable data flow, scalability and accessibility compared to MVC architectures. We know that it might appear a bit complicated to get started with, but we will explain some of the reasons that make Flux our go-to architecture. If you are already sold on Flux and need some help getting started feel free to skim down to our quick example below.

About Flux

Flux is an architecture developed by Facebook which consists of the following components: Dispatcher, Action, Store, View. There are many implementations currently in use such as flux/facebook, reflux or fluxxor. We believe Flux is the go-to resource for applications with multiple events to manage.

Let’s explain briefly each of the architecture.

MVC is based on a simple process: the Controller updates the Model and then tells the View to get the new data from the Model. Let’s take the example of multiple views associated with one model. The controller becomes quickly overcomplicated and the logic will be unnecessarily complex to extend to new views.

Flux, on the other hand, is similar to a pub-sub pattern: the View adds the Listener to the Store, if the Store changes then the View will be notified automatically and update itself.

Furthermore Flux is not only a data binding solution, it is also known for its event bus dispatcher capabilities. Data is changed by the Actions, and then all the web Actions go to the Dispatcher, making your application more predictable and easier to follow. That leads us to believe that compared to MVC, in certain case, Flux can be considered as more scalable.

If you are thinking just shut up and show me here is a diagram on how Flux works:

Create a package.json file by cloning and then use npm install to install the libraries needed for this demo.

Step 2: Action

Action can triggered by UI actions such as getting details from a click to the master branch, submitting a form or some changes or sending a message by clicking on a button. Note that you can call API utils in an action to help handling your application logic. All of these actions are send to the Dispatcher but only one can pass through the dispatcher at a time.

Step 3: Dispatcher

The dispatcher is the central hub of the data flow in Flux, it gets the payload data/messages from the actions and sends them to their registered stores. The dispatcher utilizes a ‘waitfor()’ method to make a sequence for the Store processing the data. It is singleton by design and acts as an event bus. One single dispatch makes a simple flow to figure out what exactly happens after the action trigger.

Step 4: Store

The store contains the state of application dat, and handle dispatched actions (note that it has no direct setter methods). The Store uses a similar feature to ‘action.type’ to find which dispatched action it can handle. If the Store is changed, it will emit a change event which will update the subscribed view.

Thoughts

Simplicity and predictability: Flux’s one direction data flow makes the app’s logic easier to handle in your code. Flux’s architecture makes the structure easy to comprehend even as you scale and add more complex components to your code. Although we still find use for MVC, we find ourselves saving time and resources by using Flux.

We hope this helped you get started with Flux and you can see the benefits of using Flux yourself. Feel free to let us know what you think of Flux on Twitter.

Share this post

Scan to open in WeChat

Stay tuned

Follow our newsletter or our WeChat account; every other week you'll receive news about what we're up to, our events and our insights on digital products, omnichannel, cross-border ecommerce or whatever the team fancies.