Understanding Redux
Lately, there’s been a lot of fuss around React. It is the hottest thing around at the moment. Most of the companies, at least in my area, are looking for React developers, Angular & Vue are being left behind. This has forced most developers to get at least familiar with the library.
Developers with a decent understanding of Javascript and the ES6 syntax have no problem getting to know React, it takes an hour or two to get the hang of everything that’s built into the framework, and after that first period of getting to know the framework passes, you start to see the flaws.
But then, you realize you are a Javascript developer, and that there’s a module on npm for everything that you will ever need! This holds true for React as well. Pretty much every single flaw of React can be solved with a simple
npm install <deus-ex-machina>
One of the most important libraries that solve a problem React has, is Redux. You’ve probably heard of it. Everyone talks about it, but nobody actually explains what the fuck it is.
If we go to the homepage of Redux we can see their official description of Redux, it says:
Redux is a predictable state container for JavaScript apps.
You are probably asking yourself what that even means, I know, I felt the same way when I first read it. Let’s break it down and get a better understanding of what this sentence actually means.
First, let’s talk about the actual problem? What does Redux solve for us?
If you’re familiar with React, you will know that every single component has it’s own state and that the only way to pass down data from parent components into child components are props. This functions extremely well, but it also gets extremely messy when for example we have two components that don’t have a direct parent-child relationship but they both depend on the same data.
Lets put ourselves into a situation where the above is true, and the data we need in both components comes from some API. To get the data to both components, we have several options.
- Since entire React apps are usually just a single component that renders other components inside it, we know that the two components we need have at least one mutual parent. We could move the API call into that component and just pass down the data as a prop until we get it into both of the components.
This isn’t an optimal solution for several reasons. Most importantly, we will have the data going through components that have no use for the data except to pass it down where it needs to go, that’s not good. Another issue is that we may end up passing down the data through several components, and it gets really hard to track where and what we passed down. It makes refactoring and code review a nightmare. Also, if someone else reads your code, they will hunt you down and murder you. - We can ping the API from componentDidMount() in both components. I don’t think I need to write why this is an awful solution. If we follow the DRY methodology, this solution goes out the window immediately.
This is what Redux helps us with. Redux gives us access to a so called store, you can think of the store as a project-wide state. You can change the state from anywhere, and grab the state from anywhere. For a component to have access to the store though, you have to connect it. Every component that has access to the store becomes what we call a “container”, or a smart component.
There are several things you need to pay attention to when using Redux. Changing the state of the store is done a bit different than changing the component state in React.
In React we would just call:
this.setState({ key: newValue})
In Redux, we have to write a bit more code. The general flow of Redux looks pretty much like this:
As we can see in the diagram above, the first thing that happens is that when a user triggers an event, an “action creator” is called.
An action creator is nothing else than a function that returns an object with the type of the action, and some payload. We call that object an “action”.
That action can go through some middleware, but we’re going to ignore that this time.
After going through the middleware, the action is going to flow into all the reducers that we have written. Reducers are pure functions that return a new state object and cause a rerender of the containers that depend on the data.
Every reducer takes in the current state and an action as parameters and returns a new version of the state. If you remember, we defined a type property in the action we created. This type property helps reducers know when it is their turn to change the state. Reducers change the state differently depending on the action type, usually we have one reducer per action type. Keep in mind that reducers shouldn’t return a mutated version of the current state, reducers should return a brand new object every time or else you’re gonna end up in a lot of problems.
This means that for every event we have that needs to change the Redux store, we need to have an action creator and a reducer to achieve what we want.
All in all, Redux helps a lot, but it takes some getting used to. Putting in some time into understanding Redux will make you a better developer for sure, especially if you’re working with React, it will change the way you write your apps.
I have intentionally not included any code into this post, because I feel like it’s much more important to understand why we need Redux, and the theory behind it, than to see the code. If you wish to see how all this works in practice, you can check out the official Redux page, they have a pretty good tutorial.
Next time, I’m going to go into middleware and what middleware helps us achieve.
Until then, happy coding!
This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more product & design stories featured by the Journal team.