Why should you be using Redux with Angular?
Quick introduction: how to implement Redux into an Angular App
Redux is one of the coolest technologies in the Front End development world today. Nevertheless, many people have no clue how to incorporate it into their applications or even why they should. In the first place this post is a simple introduction to Redux. Also, we want to share how it can be added to an Angular application. Additionally, we will give some real examples of how Redux can be used to help you understand the value of this savvy technology in a simple and practical way!
Redux: one of the hottest libraries for Front End
In the case you’ve never heard of Redux, you may be wondering what exactly it is and why you should use it. Redux is one the hottest libraries for Front End out there. Therefore, it is gaining more and more traction from developers in the industry every day, and transforming the way applications are built. At the same time, it enables a new way to conceive applications by using an unidirectional dataflow. As a result, this gives you better control over your application state and tools to eradicate issues associated to data mutability.
According to the Redux official documentation, it is “a predictable state container for javascript apps.” In fact, it is an incredibly lightweight (2kB including dependencies) implementation of Flux.
What is Flux?
Well, Flux is a data flow architecture created by Facebook back in 2014. Although it was meant to be used by ReactJS applications, it’s actually technology agnostic. Back then, the main purpose was to replace the bidirectional data flow that traditional architectures like MVC encourage for an unidirectional one. If you have ever been in a chaotic apocalyptic program, trying to figure out which view is updating a particular model using getters and setters, then you can probably understand why having an unidirectional dataflow is both convenient and beneficial.
In Flux, a dispatcher sends actions to stores and updates views in an unidirectional data flow. Therefore, it makes debugging easier and drastically reduces the probability of introducing bugs caused by cascading data changes.
Indeed Redux implements Flux concepts, but also has some differences:
- Single source of truth, meaning the entire application state will be held in one and one place only
- The immutability of data
- There are no dispatcher
Redux and Flux
Moreover, you can think of a Redux’s store as a tree, where you can’t change a node because data is immutable. So you’ll need to create a copy of the last node and perform your changes there. By doing this, you can always know the different states your application has been through and implementing features like time travelling becomes a breeze. This approach also favors debugging and testing, since you can isolate actions and debug/test them separately. In addition, the immutability of data enables the use of an invaluable tool called Redux Devtools, which provides time travelling, debugging functionality and other great features to accurately observe the state of your applications.
Notably, Redux cycle is really simple, as expressed in the following diagram:
The state of the application is kept in a data store, which provides information to be rendered by views. When a view triggers an action, this action is processed by a reducer. As a consequence, this generates a new state that updates the application state. For this reason views observing the store are notified of the change and are updated accordingly.
So Redux is simply based on: Actions, Reducers and a Store. Let’s go a bit deeper into each.