Redux made its appearance in 2015 to create a more predictable data store in your applications. And it was a game changer. Back then, creating a new large application involving React involved Redux, there was no other option (sorry Flux) and it was great. But time has passed and the ecosystem has grown a lot. We have experienced the creation of (many) different frameworks, and React itself has been updated with pure components, the new hooks… Even with all the new things out there, I believe that Redux is still important nowadays, and here is why.
Let’s imagine that we created our application in 2013, before all these new fancy frameworks came up. It is an old, but robust application based in an own framework we created following the MVC pattern. The application grew and 7 years later it is still working. The project components are well structured, but the logic to retrieve the data is growing more and more and there is not a clear way to share data between components. Whenever you need to create a new component you need to think about where to get the data to display it. Whenever you need to send a piece of information from one component to another you need to involve other files of your application and the data flow is not easy to understand. And it is when you have to explain how it works for a new teammate in the company when you know something is now working as it should.
- The data flow is very simple and predictable.
- Each component knows when to be updated as they are subscribed to the store changes. No more connection files between components and executing functions between them.
- It is a known pattern, which is very easy to explain to newcomers.
- It provides tools to debug the store, making it easier to find where the inconsistency is.
- And last, but not least, it can be tested. In the past, the data was coming from different places and it was very difficult to test.
It will not be the only case, if you are curious why Paypal was studying the possibility to go back to Redux from Apollo Client watch the following video — https://www.youtube.com/watch?v=zhmIox9iZ9A
Ok, but can we include Redux in our old MVC-like framework? Yes, we can (and should) — and here is how.
Let’s dive into a basic implementation and we will show the differences between using Redux and the legacy flow in the following articles.
Redux implementation in Vanilla JS
Let’s start by initialising the store with a reducer and a callback to be executed when the store is updated.
As we had our application using a custom framework based on the MVC, it made sense to, somehow, connect the model of each component with the Redux store. We wanted each model to react independently to the store changes, but at the same time, keeping it as simple as possible. In order to do that, when the model is initialised, we execute a function in our store root file that pushes the model to an array.
And now, we can simply change our subscribe callback function to trigger a change in all the models of the array.
Now, everytime the store is updated, each of our connected models will execute the function onStoreChange receiving the whole store (this is a bad practice as we will see in a next post and how to solve it). But we achieved what we wanted, they can react independently to these changes, deciding what to do with this new information.
Github repo where we will be adding the advances we do in each post -> https://github.com/OBellon/vanilla-redux