About Redux

Redux is a third-party library that we can use to manage the global state in a web application. And I say web application because Redux is a complete standalone library that we could use with any framework or even Vanilla JavaScript. However, Redux has always been tightly linked to React, and they are quite easy to connect.

Now, the big idea behind Redux is that all the global state in your application can be stored inside this one globally accessible store which we can then update using actions. And if this sounds familiar, it's because the useReducer hook implements a very similar pattern. So updating state by dispatching actions. Remember and in fact, the mechanism behind Redux and useReducer is so similar that I will assume that you know how to use useReducer and build the teaching of Redux onto the knowledge that you already have. So conceptually, if we think about this, Redux is actually quite similar to combining the Context API with the useReducer hook.

When to use Redux ...

Use a global state management library like Redux, only when you have lots of global UI state that you need to update frequently. And remember that UI state basically means state that is not fetched from a server that would be a remote state. So UI state is simply data about the UI itself or data that doesn't need to be communicated to an API or so. And this distinction is really important because, remember for the global remote state we have many better options nowadays like React Query, SWR, or even a tool that is kind of included in the modern Redux Toolkit, which is Redux Toolkit Query. So again, do you need to manage a lot of non-remote state in your app, then Redux might be perfect for that. But the truth is that most global state is actually remote which is the reason why so many apps don't use Redux anymore.

Mechanics of Redux - how redux works

So with useReducer when we want to update the state from an event handler in a component, we start by creating an action. This action is simply an object that usually contains a type and a payload, which is information about how the state should be updated. We then dispatch that action to a so-called reducer function. The reducer takes the action type and the payload and, together with the current state, calculates the next state, so the new state value. And to finish as the state updates, of course, the component that originated the state transition will re-render. So this mechanism should be familiar to you at this point because now we're gonna add two more things onto this in order to learn how Redux works.

So the first difference between useReducer and Redux is that in Redux, we actually dispatch actions not simply to the reducer but to the store that we talked about at the beginning. So this store is a centralized container where all global state lives. It's like the single source of truth of all global state across the entire application. The store is also where one or multiple reducers live. And just as a reminder, each reducer must be a pure function that has the single task of calculating the next state based on the action that was dispatched to the store and the current state that's already in the store as well. Now, you might be wondering why there are multiple reducers in this store. Well, it's because we should create one reducer per application feature or per data domain in order to keep things separated. For example, in a shopping app, you could have one reducer for the shopping cart, one for some user data, and one for the application color theme, for example. Finally, any component that consumes the state that has been updated in the store will, as always, get re-rendered by React, at least if we're assuming that reusing Redux together with a React app. Okay, so that's the Redux store, but now let's focus on the action again.

So in the real world, when we use Redux we usually use functions called action creators to automate the process of writing actions. So basically, instead of always writing these action objects by hand, we create functions that do this automatically. This has the advantage of keeping all actions in one central place, which reduces bucks because developers don't have to remember the exact action type strings. Just note that this is optional and not a feature of Redux. It's just how we build real-world Redux apps. Then the rest of the process is of course, just what I explained before. Okay, so let's recap how this Redux cycle works, as I like to call it. So to update global state with Redux, we start by calling an action creator in a component and then dispatch the action that resulted from the action creator. This action will then reach the store, where the right reducer will pick it up and update the state according to the instructions. This then triggers a re-render of the UI where the cycle finishes. And the big goal of all this is to make the state update logic separate from the rest of the application.

And there you have it; this is how Redux works.