React Flux Architecture: the Foundation of Redux

Flux is an application architecture for React.js that is typically associated with the Redux library for state management. According to Facebook, Flux “complements React’s composable view components by utilizing a unidirectional data flow.” I know, I know, what the hell is that supposed to mean? In this guide I’m going to explain how a Flux architecture works so you can effortlessly understand the way Redux operates.

If you want to learn more about React in general, check out my React playlist, or start reading my article series with an introduction to React.

Contents

• Flux Overview
• Dispatcher: the Hub
• Stores: the State
• Views and Controller-Views: the Display
• Actions: the Data

Flux Overview

All Flux architectures have three major parts: the dispatcher, the store, and the views. We’ll look at each of these parts in turn. But first, it’s important to understand what is meant by a “unidirectional data flow”

The above diagram is the way Facebook visually represents a unidirectional data flow. But as you may have noticed, the extra arrow going from “View” to the “Action” above contradicts that. So a better way to visualize this might be as a cycle, as shown below.

Here we have an endless cycle of data flow, and it is constantly going in the same direction. There is no need to understand this right away, but I’m putting this right at the beginning for reference. Below is an overview of how the data flows in a Flux application.

1. The application state lives in – you guessed it – the store, which provides data to the views.
2. The views display data from the store and may also create new data, which it sends to the dispatcher as an action.
3. An action is nothing but a JavaScript object containing the data and type of data to be stored. It goes to the dispatcher.
4. The dispatcher processes the data in the action and sends it to the store.
5. When the store updates, it in turn updates the views, and the cycle may continue.

With this kind of unidirectional (going in one direction) data flow in mind, we can now look at each of the parts in more detail.

Dispatcher: the Hub

The dispatcher is a simple part of the Flux architecture, and serves mainly to separate the logic of storing data from the display.

The dispatcher is a central hub that manages all data flow, distributing the actions (which contain the data) to the stores (which store that data). A dispatcher is by its nature very simple, only serving to accept actions and send them to the stores.

But the dispatcher also has access to functions that the store provides, functions that determine the type of data and how it should be stored. As these functions are not technically part of the dispatcher, we’ll look into how they work under Stores below.

Stores: the State

If you’re familiar with MVC architectures, which Flux was designed to replace, then you can think of stores as similar to an MVC model. But while models represent a single type of data (for example, Posts or Comments) stores can manage the state of the entire application. More commonly, your application will have several stores for each part of your application.

It’s important to remember that React applications handle data quite differently from other apps. Whereas models typically represent data from a database (like MongoDB or Postgres), a Flux store represents state, which is the data the application is currently using. You can of course retrieve data from a database, but that data goes into the application’s state (in this case, as part of the store) where the views can access it.

Remember those special functions I mentioned that the dispatcher has access to? When actions (data) are sent to the store, these functions must determine what to do with the data (a.k.a. the payload). The function will always contain a switch statement that runs different code depending on the type of action (for example, FETCH_DATA or POST), and then use hooks to “hook into” the store’s internal methods for storing that data.

Any time the store updates, an event fires. This is how the views know when the state has changed and that they need to re-render to display the new data.

Views and Controller-Views: the Display

View is just a fancy word for component, so if you know what a React component is then you understand views. But Flux architectures have another type of view: controller-VIEWS. These special components are typically parents of many other components. They are responsible for getting the application state from the store and passing it down to all of their children (like an inheritance, I guess).

One of the basic rules of React is: each component should only have one purpose.

If the purpose of a view is to display data from the store, then the controller-view’s purpose is to get that data in the first place.

Actions: the Data

Actions are plain JavaScript objects containing the type of request and the payload, which is the data itself. A typical action might look like this:

As you may have guessed, it can be annoying to have to constantly create these actions from scratch. So instead, we often use special functions called action creators which accept the data and create the action for us. Following the above example, we could use an action creator like this: postComment('somerandomuser', 'hello!!!') and the postComment function would create that action for us.

Conclusion

That’s pretty much all there is to understanding Flux! Of course you could go into things like dependency updates, which complicate things a bit, but this guide has been about the basics.

If Flux seems terribly abstract, I suggest just diving into the Redux library, which is the practical manifestation of Flux, and then coming back here to understand why Redux works the way it does.

For more information on the Flux architecture, you can visit the Flux docs from Facebook.