Flux Pattern Architecture in React
Inspecting the architectural design patterns
Handling data inside a client-side application is a bit challenging and complex task. Today we’re looking at one method of handling complex data proposed by Facebook called Flux Architecture at their F8 conference.
We’ll need a better data handling approach. With more data, we’ll have more to keep track of. Our code is required to handle more data and application state with new features. From asynchronous server responses to locally-generated, unsynchronized data, we have to not only keep track of this data but also tie it to the view in the same way.
What is Flux?
Flux is a word made up to describe one-way (unidirectional) data flow with very specific events and listeners. There’s no official Flux library, but it’s a pattern we can use react and many works.
Flux is an observer pattern
Why We need Flux?
Assume we have two objects called p and q. When p changes, we want q to change with it. There are two ways to do this:
1. Declarative: p updates, then call a method on q.
This is initially simple, but experience shows us that ultimately we have a problem because we have tightly coupled p to q. If we want to add r, we now need to update p.
Now imagine we have hundreds of things changing in the DOM. Whenever we add a component, we need to find all the things that might update it and modify them. Imagine that r needs to respond to changes in p and q. Everything knows about everything else.
2. Observer Pattern: P triggers an event. Q is listening (Flux).
In an observer pattern, when p updates, it triggers an event. q subscribes to that event. When the event is triggered, the method on q gets called.
This makes our p slightly more complex initially (though we can fix this with a library or a prototype).
The observer pattern allows us to decouple p from q. It makes it much easier to extend because if we want to make r respond to p, we now only need to listen to it.
Initially, we have written more code, but ultimately we have a more scalable, decoupled architecture.
Facebook people often talk about one-way data flow when talking about Flux. This simply means that the event is triggered on one element, and listened to by the other. Data flows from p to q via the event, rather than from p to q and back to p again, as would be the case if p called a method on q and got the return value.
Flux libraries are like glasses: you’ll know when you need them — Dan Abramov
Model-View-Controller — MVC
One of the more common design patterns is called the MVC design pattern, which stands for model, view, controller. This pattern organizes your code into three buckets:
- Model: stores & manages data.
The Model component corresponds to all the data-related logic that the user works with.
2. View: Graphical User Interface
The view is a visual representation of the data- like a chart, diagram, table, form. The view contains all functionality that directly interacts with the user — like clicking a button or an enter event.
3. Controller: Brains of the application.
The controller connects the model and view. The controller converts inputs from the view to demands to retrieve/update data in the model. The controller receives input from view, uses logic to translate the input to a demand for the model, the model grabs the data, the controller passes data from the model back to the view for the user to see in a nice display.
As applications scale, the MVC data flow can become more of a problem because MVC applications have data that can move in multiple directions, creating two-way data flows. Code is difficult to maintain. If we want to iterate on problems quickly, this way of writing the code is not going to work.
Flux Pattern
In MVC, the relationship between components gets complicated. It becomes hard to scale the application. Data in a Flux application flows in a single direction. Facebook solved this problem with the creation of the Flux Architecture to React — a design pattern that only allows data to flow in one direction while working in conjunction with React to only update a web page when the state of a component changes.
There are four distinct roles for dealing with data in the flux methodology:
- Action
The action is what triggers the sequence of events that will take place that will ultimately end up with the UI to be re-rendered in React. An action has a type property and the new data:
The type property describes the action and the payload is the new data that is passed. That payload could be of any type (object, string, etc.) depending upon the action creator it will be used for. In this instance, they will probably both be objects since we will probably be dealing with a user ID and a username or email address.
These action creators are the responsibility of the dispatcher when invoked.
2. Dispatcher
The dispatcher is essentially the traffic controller in this scenario. It’s a directory of callback functions that will be used to update the store. Like a police dispatcher will tell a cop car where to go for an emergency, a Flux Dispatcher tells us what an action should do.
3. Store
The store deals with our application state. In Flux, we can have multiple stores, one for each component if we wanted to. State is an object that holds key: value pairs that assist in the rendering of that particular component and/or its children.
These components will use the state they have in common through the passing of props. This continues to promote that unidirectional data flow by passing the logic to be used to update the state in the stateful class component and then render the actual props that the component will display on screen after the logic has been executed.
4. View
The view of the application does not change until the state has been updated. This prevents automatic re-rendering of components that are static or don’t need to be changed. Only the components whose state has changed will be updated.
Full implementation of Flux architecture
Let’s take a look at a full implementation of the Flux architecture. Here, if I add the support of AMD, CommonJS, and global usage, we end up with 66 lines of code, 1.7KB plain or 795 bytes after minification JavaScript.
Cycles
One way data flow does not preclude cycles.
Popular Implementations of Flux
Now that you have got an overall idea of the Flux architecture, let’s take a look at a few of the famous Flux implementations.
Redux — According to GitHub, Redux is a predictable state container for JavaScript apps. Many of the concepts are similar to functional programming, and all the data is kept in a single store.
Irrespective of the application size, Redux is always a single object, quite unlike Flux, which keeps separate stores for different kinds of data. If there are manipulations to be made on the data, it doesn’t affect the state. In this way, the state is immutable.
All updates and manipulations are done on a state tree. But this does not make the application slow as the data can be shared among several versions of the state tree. The updates on the application state are done through Actions, which are plain objects themselves but contain a property depicting the kind of action performed. The data that describes the action will also be included.
The Store’s Dispatcher will dispatch the action and, from there, it goes to the Reducer, and then to the current state tree. Here, the actions of the application will be described, i.e. the different things the application can do. Just a single reducer would be enough for the state transformation and action.
- Reflux — It is one of the most popular implementations of Flux. But there are some basic differences between the two. Reflux doesn’t use a Dispatcher; instead, each Action is a Dispatcher. As the Actions themselves are functions, there are no action creators. And the best thing about Reflux is that it is more concise and streamlined, with fewer requirements around repetitive code.
- Fluxxor — Fluxxor makes use of a number of tools and Flux architecture to build JS data layers. In order to enjoy the full functionality of Fluxxor, you will have to make it work with React as the view layer.
- Flummox — Flummox has three components, namely, Actions, Stores, and Flux. In Flummox, you create some Actions, then create a Store that is responsive to those Actions. In the next stage, you bring them together in Flux and use it in a View. Each of the Flummox components is represented by a class, and you extend from this base class.
- Alt — Modeled after Flux, Alt is a library that facilitates the managing of state in JavaScript applications. You can install Alt if you are installing package managers like nom or bower. Alt gives you the benefit of Flux, but with a better syntax.
MVC vs Flux
Pros:
Flux architecture is better in an application where views don’t map directly to domain stores. To put it in a different way, when views can create actions that will update many stores and stores can trigger changes that will update many views.
Actions can be persisted and then replayed.
Cons:
Flux can add unnecessary complexity to an application where each view maps to one store. In this kind of application, a separation between view and store is enough.
If you need to know any kind of additional information about flux, please refer to the flux documentation given below.
Flux Documentation — https://facebook.github.io/flux/docs/overview
Wrap up
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!
Happy Coding :)
