Understanding the Redux paradigm
Lately I’ve been hearing a lot about Redux, it’s very trendy between my partners here at Tryolabs. It is so trendy that even one hard core backend developer who hated UI development started to love it just because of Redux. With this as a tipping point I decided that it was time to get my hands on it.
If you’re used to MVC based architectures and want to know more about Redux, this post might be of help. Otherwise, you’re completely welcome to read some thoughts on Redux :)
MVC to Flux
When high-level comparing to MVC architectures, Redux offers the Stores that will save all our data, similar to what Models were. Then the Actions and the Dispatcher are the user events, the data modifications and their handlers. Finally React Views which replace the Views.
The main characteristic of Redux over Flux are the Reducers. A Reducer is a generic function that takes an Action and its current State and invokes the function that matches the action. There is only one Store, that we’ll call it Redux Store, which it’s initialized by the combination of all the Reducers created.
The flow goes like this: Data comes into the application and we create an Action. Once created we send it through the Redux Store Dispatcher to each Reducer. Each Reducer decides if uses the payload from the Action to update its internal state or not. After all the Reducers complete their update, the React Views will re-render with the new states. One of the biggest changes is the unidirectional data flow and that there is only one way to do things. First you’ll have an Action that affects Reducers that reflects their changes on Views, and then you’ll start all over again.
If you want to learn more about Actions, Reducers and Stores, Redux has a very complete documentation that you should look at.
While I was researching I found out about another cool library, I’m talking about Immutable JS. Since Redux is inspired by functional programming and immutable data, this library is very helpful because you can make changes on your states without worrying about unwanted mutation later. In other words when you create for example an Immutable List, the initial state will remain the same forever, if you add or remove an element it will create a new Immutable List with the update. This is really cool and you can check out the docs because it has a lot of functions that can make your job easier.
Coming back to Redux, I have only tried it for a week and I feel that I’m already falling in love with it since it seems to offer the one recipe to solve every problem. Whenever you want to add a new user interaction you just create the action, dispatch it and solve it in the reducers whether is useful or not the update and later re-render the views, that simple.
I’m aware that this new paradigm might cause some headaches at first, but leaving behind all the MVC frameworks and the always_changing design pattern sounds nice at first.
The biggest challenge to deal with when starting to use Redux is just a head change.
Originally published at blog.tryolabs.com on April 19, 2016. Written by Lucía González.