Redux with React

What is Redux?

Simply, this is a React management library for JavaScript Apps. If you don't know what state management is, It is managing state to keep data synced, shared, and updated across the application or necessary multiple data flows.

A little bit of background

The Redux was developed by Dan Abramov & Andrew Clark in 2015. With the inspiration of Flux. Flux is an application architecture that Facebook uses for building client-side web applications. It is more of a pattern to manage the state rather than a library or a framework. Redux is built up on that idea but in quite a different way.

Does it only work with react?

No, Redux can work with JavaScript libraries, frameworks, or anywhere even with vanilla JavaScript. Because it is just plain JavaScript. It can be run anywhere that JavaScript runs. Also, Specific bindings are available for most of the UI libraries and frameworks to work with Redux.

But, Redux is mostly popular to work with React and specially made for working with React.

Why Redux for React,

Yeah, we have props and React Context already. But we know that when we use props in React, it gets messy. When the application grows, It decreases the readability, understandability, and even can be pushed to infinite loops by losing track.

When it comes to React Context, it is ok to use React Context until your application is not a large-scale, enterprise-level application, or an application with high-frequency state changes.

Here you can see that when an application has lots of things going through, either it will have to have lots of nested providers or one or two complex providers. So either way, it would be a mess.

We were talking about "Why Redux for React", So the direct reason is that Redux has solutions for all of those problems we discussed right now.

How Redux works

Redux is all about having one data store for the entire application. It can be authentication states, user inputs or anything. All goes to this one store. It even sounds like a mess, right? No, we don't need to manage the entire store all the time, Therefore it won't be a mess. I will explain that within the upcoming few paragraphs.

So, the purpose of using this Redux in our React application is to track all the changes that we need, store them, and for reacting to those state changes in related components.

For that, as you can see in the diagram, there is a central data storage, and components can set up a subscription to the central-storage. So, whenever the data changes, the storage notifies the subscribed components. And it can directly use the changed data.

The good thing here is that you have ways to manage data or action loads using multiple reducers or data slices in different ways with different support libraries.

So that is how we use data in the storage. Of course, we need to store state changes as well. However, components cannot directly manipulate the data in the storage. For that, as you can see in the diagram, we have a concept called reducer functions. This function is responsible for manipulating the data that is stored in our central store.

But, how can we connect or use those reducers functions?

For example, a login state change or a click of a button may need to change the central store's state. For that, you can see there is something called "action" in the diagram. We need to trigger this action from the component on a state change. If I use the word from Redux world instead of the word 'trigger'. It is, we need to dispatch the action from a component.

The action is a simple JavaScript operation that describe the kind of operation that needs to be performed on the dispatch call. Also, it includes the payload, which is the data that can be used in the reducer to perform changes. So, on the dispatch, the reducer function will run according to the action.

Story of the diagram in Short

If I conclude the diagram by reminding you the concept, There is a central storage. Components can have a subscription for the storage. And get changes from the storage. When data needs to be manipulated, we can dispatch an action from a component. Then the changes described in the action will be made by the reducer function. Then it will replace the existing state from the new state. That's the story of the Redux.

One thing to keep in mind is that the reducer function must be pure, side effect free, and a synchronous function. You will understand it more in the next few paragraphs.

Side Effects, Async task & Redux

In previous paragraph I mentioned that reducer function should be pure, side effect free,and a synchronous function. So, how can we work in a situation that we have to use any of those on a state change?

For example, you may have to update the database on a state change. One option is, you can get the current state from the store and manipulate it from the component and then save the changes in the store. Then we will not need some reducers. Because, all the manipulation part is happening in the component. If it is your personal preference and not harmful to the logic, then it is not a problem. But it is not the main idea behind using Redux.
Another option is, you can write your data manipulation code in reducers and send your HTTP request or any of your side effect on that change in the component. That is also not an issue, you can do it as well.

Or the best way is you can use a middleware.

Use of middle ware in Redux

This is the suggested way to extend Redux with custom functionality. Basically this acts between the action and the reducer function. We can use this for logging, crash reporting, performing asynchronous tasks, etc.