Do I need Redux?

In this simple article we’ll be talking about:

• What’s Redux
• How it works
• Where does it work
• Why should you use it

If you are reading this post, you’re probably having difficulties understanding what Redux does to your project, while it’d be better to have a clear vision of what it is. Let’s dive in!

What’s Redux

Redux is a library for handling the data logic (also called business logic) in front-end applications. It is an implementation of a pattern called Flux (created by Facebook), with some differences. Flux is a pattern, not a library, which means we can write a Flux architecture on paper. Redux is the simplest and most famous library implementing Flux, and the main difference from it is that it uses one single store.

Basically, it provides a place where we can store all of our application data (ex. the user’s name, his todo list, at which point he is on a stepper component…) and all the tools needed to modify them.

Ooops, forgive me! I meant replace them. You might think it’s not a big difference but actually it is, and it’s what makes Redux so powerful: immutability.

This means that if in our store there’s a list of todos, when we push a new one in the list we actually don’t want to push it, we want to copy our array of todos, append the new one, and replace the old array. Both the old array and the new array define a state in the application: there is a state with n todos, and then there’ll be a state with n+1 todos.

You can think of a state as a picture of your store when data changes.

Awesome! Time for the next chapter.

How it works

Redux gives us this tools:

• A store, which keeps all of our data
• Actions, which are objects that work like triggers: there could be an ADD_TODO action, and a DELETE_TODO action, and each action comes with a payload: in the case of ADD_TODO, it would be the todo itself, in the case of DELETE_TODO, it would be the id of the todo.
• Reducers, which are functions that handle the actions and replace the old state with a new one.

It’s important to understand that Actions do nothing, they just carry information: what to do, and what’s the payload. Reducers see the action coming, they go like “Ooooh, it’s a DELETE_TODO action, and it gave me an id. Let’s delete that todo and replace the state”.

Got it? Wonderful!

NB. Actually, the Redux ecosystem gives us more than these 3 things: for example, we can use Middlewares or we can use Thunk and Saga to deal with asynchronous functions, but eventually we’ll talk about them in another article. 😃

Where does it work

Redux works with basically any JavaScript application: you could use it with React, Angular, Vue, even with plain JavaScript. Redux doesn’t depend on anything! It’s very probable to see Redux in a React application, simply because React is a view library and shouldn’t care about the data model, even if you can absolutely live without Redux using React’s states.

Also, using Redux makes it easier to switch from a library or framework to another: since your data logic is tied to Redux, you could easily reuse the same structure for your new project.

Why should I use it?

Redux is very powerful, and gives us the following advantages out of the box:

• Time travelling and undo-redo (there’s no possibility to mess-up with the store, you can always switch to a previous state and viceversa)
• Sync different parts of the application (their data will come from the same “place”)
• Easily testable state (you’ll use pure functions which return the same thing if the input parameters remain the same)
• Predictable state (you know what the state will look like before passing an action to a reducer)
• Debugging tools to be used with the browser (you’ll feel like a DJ, I promise)
• Offline data persistence (you can save your state in localStorage and grab it back later)
• Lots of helper libraries (routing, forms, saga, thunk, etc…)

If your application could benefit from any of this concepts, you should definitely think about using Redux. However, Redux comes with a cost: first you’ll have to learn it and make some practice, in order to start thinking in the “Redux way”. And second, you’ll have to get good at building the architecture for your app, since Redux adds some code to your application, which can be a bit tedious at first, but if your app is getting bigger, you’ll definitely be happy to have it.

In general, using Redux makes the most sense if you need to sync lots of components in your application. You would definitely have benefits with this scenario, since you’ll handle the data changes in a single place (the store) and all the components connected to Redux will update accordingly. Awesome!