This is the million dollar React question for beginners. You can’t dig into React without hearing a lot about Redux. However for many people who start learning, it can make no sense, they can’t understand it, or if they do it just seems like boilerplate code.
Let’s explore if you need to learn it, and if so do you need to learn it now? OR can you defer it for later?
Why Redux?
It’s all about managing application state. Where do you want to store it. Who is privileged to update it. How do you want to manage it. This is a technical discussion but also a people one. Do you have a single person with all the code in their head? Or a team of 10 or 100 developers sharing a code base and needing to collaborate?
Redux offers a specific approach to handing state in your application.
If you are using React, you might already appreciated that state has a special place in it’s heart. Whether you are using hooks or class-based components, state is explicitly called out, and there are prescribed ways to get and set state. The whole React library is based on the idea of a given state, and way to render that into a view.
For simple projects, such as you would do as a beginner – for example a TODO list – there isn’t a lot of state. There aren’t a lot of places updating that state. It is absolutely sufficient to use React’s built in state management tools, and leave out Redux. I normally approach this by keeping the state in the top-level App component, and then passing props to child components to update the state.
For bigger projects though, this gets a bit unwieldy. The problem is in a large application, you are going to end up with a lot of state, and some of it will be related via keys, as well as state that is loaded later via API calls.
For example a list of accounts with their details, a list of transactions, and perhaps additional data coming in from the server as needed. You may have components within components within components that might want to update state relating to their grandfather components or distant cousins. This gets pretty messy and the potential in teams for misunderstandings and mistakes, and it is the justification for using a state management library like Redux.
Redux was inspired by Flux, and Flux is a “way of organizing things” created by Facebook to handle state large complex applications, like Facebook. If you want to learn more about why Facebook came up with Flux, watch this video. In short – they had a lot of bugs, and they were fed up playing whack-a-mole trying to fix them, and so were their users.
Do I have to learn Redux?
That’s what you want to know right? Maybe your friends or colleagues are saying “you gotta learn it!”. But do you? Here is how to decide:
If you are learning React as a hobby, will be doing side projects for a long time and care mostly about create UIs or solving small problems then you don’t really need to learn Redux ever. Unless you want to!
If you do React in your job, or do more complicated side projects, then it is worth learning the basics of Redux for a few reasons:
- You might need some knowledge of it in your current job or future.
- Even if you don’t use it it is good to know enough about it to be able to decide if it is good for your team.
- You might be forced to use it in some code bases you work on.
- And not least… it’s potentially a great solution for managing your app state!
Where to learn Redux? I recommend the course on Scrimba – and here is why. Alternatively, Redux Essentials is a good free resource.
Your next step: If you have decided to learn Redux, put some time aside at work or at the weekend to learn it. I reckon you’ll need up to a full day of work (8 hours) to grok it and get some practice in on a toy project.
Posted by Martin Capodici
