Meet Redux, the data architecture pattern that implements a simple and predictable flow of information, adopted by numerous frameworks and advanced applications.
Redux is a data architecture pattern that allows application state to be handled in a predictable way. It is intended to reduce the number of relationships between application components and maintain a simple data flow.
Originally started by the React community, as an evolution and improvement of Flux ideas, Redux has become a cross-pattern, capable of adapting to any type of library or framework on the client side. It could even be used without the need for another Javascript framework. It can also be run on the server side or in mobile applications, so its scopes of application are very wide.
Redux is a light library, barely 2 KB in weight, so it is not also light for execution by the Javascript engine. Its community is very wide and it has been successfully adopted by large companies such as Netflix.
Redux Benefits
In short, these are the benefits of applying the Redux pattern.
- Scalable data architecture
- Greater control over data flow and application state
- Global and immutable state
These benefits are appreciated in medium to large applications, where the state of the application is constantly changing, due to many factors depending on various components.
When the application is complex, it is normal for the state to be complex as well, and if many components or pieces of software manipulate it, it is normal for there to come a time when control over “when, why and how” has been reached is lost. to the current state. This situation is kept under control much better thanks to Redux.
Current frontend needs are also greatly facilitated by using Redux, making advanced application needs very easy, such as freezing the current state of an application and delivering it as-is when the user logs back in after a few days. Even keeping the state of the user interfaces.
Redux Data Architecture Pattern
There are several more or less popular data architecture patterns adopted throughout the history of the development world in various frameworks. For example MVC (Model View Controller) or MVVM (Model View ViewModel) and you can also find various variants of these. All of these patterns specify how information flows between members of an application and how application data transits between views, models, controllers, and so on.
All the previous proposals have a feature that makes them different from Redux, since until now the changes in the state of the application could be produced from various elements of the pattern, such as views or models. This behavior produces applications where there is a lot of interaction between components, which increases their complexity and makes it difficult to debug, maintain, and ultimately, scalability.
Facebook, with the intention of simplifying current models and making it easier to predict the flow of data in the application, released Flux. Flux has its most notable feature in the flow of data, since it is always carried out in a single direction.
In summary, this diagram tells us that the “Store” contains all the data of the application, its state. The data always goes to the views in a single direction and to modify the data from the view actions are launched. Those actions, once handled by the dispatcher, can produce a State change in the Store, which in turn will travel to the view.
Flux is just a statement of intent, a pattern. Redux is an implementation of the pattern, in a lightweight library that we can use in any type of development environment, framework, etc.
The diagram with Redux evolves a bit, but maintains the essence discussed for Flux: the unidirectional flow of data and the need to request changes to them through actions.
In addition, the “Reducers” are added, which are nothing more than pure functions (we will explain this concept immediately) that are in charge of processing the actions and generating a new state, in the Store.
Three basic principles of Redux
We must engrave in our memory the three fundamental principles of Redux:
- Store as sole source of truth
- The state (State) is read-only
- Changes are made through actions (actions) and pure functions (reducers)
Store as sole source of truth
The store is the state that everyone attends to. The only valid application state is in the store. The components that need to know the status will go to the store to retrieve it.
Store data travels to components in only one direction. This means that the data-binding that we will use to send the store to the components will be 1-way, with a single address.
The state (State) is read-only
State in Redux is a single Javascript object, organized in a tree fashion (like JSON), that contains all the data that the application will handle.
An application’s state might look something like:
{ hero: “Super Me”, favorite supervillains: , lives: 5, level: 1 }
The components that handle the state data only read the data, not manipulate it. In the event that a manipulation occurs, it remains only in that component and is not transferred to the rest of the application.
To be able to alter the state of the application, actions will be used. The actions (actions) represent the only way to produce a change in the global state of the application.
The actions are descriptive of the modification to be made and are represented by a Javascript object. They contain, as a minimum, the type of action to be performed. For example “go up a level” or “subtract a life”. In addition, there are actions that require additional parameters to be described, such as the name of a supervillain to add to the list of preferred villains.
This is the form that the actions could have.
{ type: “INCREASE_LEVEL” } { type: “DECREASE_LIFE” } { type: “ADD_VILLAIN”, name: “Dr. Doom” }
As we have said, the first two actions do not require any additional data, because it is understood that they have to add or subtract a unit, but in the action of adding a villain we need to indicate the name.
Changes are made by means of pure functions
Once the actions are issued, they are processed by means of pure functions, which are called “reducers”.
The reducer always receives two parameters: an action and the previous state. It contains the logic to process such actions and as a consequence of them it can modify the state. After the logic is executed, the reducer returns the new state.
Basically our reducers could look something like this, where we have a switch with different cases for each action. Although logically, when the application becomes large, the code could be organized in another way, for example, making a function that is in charge of maintaining each part of the state.
function reducers(state, action) { switch (action.type) { case ‘INCREMENT_LEVEL’: // Execute the logic // Return a new state case ‘DECREASE_LEVEL’: // … default: return state } }
The concept of reducers as “pure functions” means that they do not cause any kind of side effect. They are in charge of modifying the state, themselves, and nothing else. This means that they do not directly modify parts of the interface, do not store in the database, do not produce Ajax requests to web services, do not call other functions to do their job, etc.
This would be the diagram of a reducer.
conclusion
We have learned the key concepts of Redux, so we hope you can get an idea of this data architecture and assess the possibility of incorporating it into your own applications.
The next step would be to implement an example using this library, but for this it was essential to clarify the concepts with which it is going to work, since from then on the code will be much clearer.
To conclude this introduction, for now, you can see the following diagram. It shows in a very visual way how the component architecture varies with and without Redux. On one side we have the diagram of components and data flow in a traditional architecture, with one and two-way data-biding, where many components are capable of manipulating the state. On the other side you have a component architecture based on Redux, where there is a store that feeds all the components and where any modification is done through an action.
As references you should consult the and if you wish, the one for the Redux with Angular course (from which I have borrowed the images to illustrate this article).
Facebook Comments
Disqus