Flux and Redux
If you are working closely with developing React applications, probably the words Flux and Redux might not be strange to you. But most of the people find these two very hard and complex. In this article, let’s go through a quick overview in these two to solve the confusions.
What are these?
Flux is an architectural pattern introduced by “Facebook” to work with React. It is a slight modification of the observer-observable pattern and it is not a library or a framework. The main feature in Flux is the concept of uni-directional data flow.
Redux is a library inspired by Flux and can be considered as an implementation of Flux. Redux makes easy to handle the state of the application and manage to display data on user actions. It is a very powerful library but also very lightweight.
Redux is a predictable state container for JavaScript apps.
But why?
This is a very common question among newbies why people use Redux or Flux? It feels like everything can be handled with React easily without any external support.
The problem is, React alone itself is not very scalable. When developing large-scale applications, it is very complex to handle the state of each component. Most of the time, the same state may needed to be mapped across multiple components. Having too many props and too messy “setStates” make the application harder to maintain.
The core problem is the tight coupling between user interactions and state changes. For complex web applications, oftentimes a single user interaction can affect many different, discrete parts of the state.
For example, when you are using Facebook chat, the number of unread message count is displayed at the top navigation bar, in the side chat menu and chat box gets highlighted as well. When you reply, all three components need to be updated. Without Flux or Redux this becomes very complex to maintain. Since Facebook ran into problems like this, they introduced Flux as the solution.
Flux
Flux pattern is constructed based on four segments organized in a uni-directional manner.
- Action
- Dispatcher
- Store
- View
In Flux, there should be a single dispatcher. But there can be multiple stores and actions. Actions are based on the functionalities of application such as create a post, delete a post, add comment etc. The view triggers actions based on user interactions and listens on its stores. Whenever the store change, the view gets updated as well.
An action contains the type(id) and some data(payload) related to that action. All the registered stores on the dispatcher get notified when an action is triggered and based on the type of action, only the appropriate stores get updated.
This makes the states completely decoupled.
Redux
Redux also developed with same segments except for the dispatcher. In Redux, the dispatcher is replaced with the reducers. The other main difference is Redux is maintaining a large single immutable store. On every action, it takes the old store, makes a copy, applies the new changes and makes it as the new store.
Similar to Flux, the components trigger the actions which organized in the same manner with the type and the payload. Based on the type, it will be dispatched to the appropriate reducer with the payload data. The reducer will make a copy of old state and apply the new changes. The components get updated from the new state.
Redux vs Flux
In Flux, multiple stores are maintained per application as a singleton object. On the other hand in Redux usually, a single store is maintained per application (But you can create more if required for complex scenarios)
In Flux, the logic of what needed to be executed based on the action is written in the store while in Redux it is written in the reducer. There can be multiple reducers but they need to be combined into a single root reducer.
The other biggest difference is Redux is maintaining an immutable state while Flux state is mutable. Having a history of states in Redux helps to implement certain tasks easily like undo and redo.
Scalability of Flux is obtained by the flexibility of adding as much as stores we need when adding additional functionalities. Redux handles this by maintaining the shared single state across all components.
