How Redux has evolved in my projects — Part 1
It was 2016 when I first discovered React. All I knew about web development until then was AngularJS and I was getting tired of it, so I needed to experiment with something else in my pet projects. React was starting to gain popularity by then and I loved it was just a rendering library, and I always have loved small frameworks which grant me freedom.
Then came Redux. If you start searching React in StackOverflow you will find some answer related to Redux before reading more than 10 questions. Looking back, I now think that I discovered it too early and I started using it without understanding it. Luckily, I learned a few things since then, but there is a lot for me to discover.
So, what is Redux?
Redux is a state management library for Javascript (and really lightweight). It is based in Flux made by Facebook. It is not made for specifically for React, however, it suits it really good. React hides DOM manipulation and asynchronicity, but the state management is up to you and this is where Redux comes in.
Redux tries to make state management predictable by following three principles:
- Single source of truth. Unlike Flux, Redux stores all the state of the app in a single store. It can be seen as a tree representation of the current state.
- Read-only state. To change it, you must dispatch actions. We will get to that later.
- State changes must be pure functions. This is a concept which comes from functional programming. They are functions which have no side effects. Side effects are http calls, database operations, etc.
How does it work?
I am going to build a little example and I will explain it step by step.
Firstly, we have the store. It is a simple object, period. As long as something fits inside an object, it can be part of the state.
Now, if we want to modify the state we need actions (remember rule #2). An action is an object which indicates what we want to modify. Here I am using a pattern called action creators which are functions for creating actions.
Lastly, we need to define how the state should change with each action. Reducers are the responsible for carrying out this step. They are pure functions which, given a state and an action, they always return the same state. They are deterministic. Usually, reducer functions are a big switch which checks the action type and performs a pure modification to the current state
If we want the reducers to be deterministic, we need the state to be immutable. This means that, each operation in the state should return a modified copy of the state. For example:
const arrayOfNumbers = [1,2,3]
const result = arrayOfNumbers.filter(number => number < 2)console.log(arrayOfNumbers) // [1,2,3]
console.log(result) // [1,2]
This way of handling data provides several benefits as predictability which Redux aims for. Mutation hides change which create side effects, therefore, immutability is easier to debug and less error prone.
Enough talking for today. In the next post I will show how I started using Redux in my projects and how would I use it now after learning a few things.
In the meantime you can follow me on Twitter @MiguelColeto and on Github @Cotel. Thank you for reading me 😄
