React indeed was an instant hit with its component-based UI development. It enabled even complex UX to be divided into simpler components. React offered the flexibility and simplicity that none of the existing JavaScript frameworks offered for front-end development. And ReactJS became so popular that the technology solutions surrounding it were over-engineered. The lack of an organised approach towards state management was sorely missed when Facebook (now Meta) first introduced React. With this Redux came into the picture resolving the issue of unidirectional state flow in React.
We have discussed why React Redux combination is used together, its advantages, disadvantages in our earlier blogs. However, in this blog, we will take a deep dive and understand if Redux is still relevant in 2021? Or, can we manage to develop front-end applications using just React without Redux intervention?
Redux is used by most developers without a valid reason, more as a convention. But, at times, Redux does more harm than good. In this section, let’s see the reasons why Redux can be avoided.
There are a few downsides to using Redux in the longer run. As most of us know, Redux is partly inspired by Flux. It means a lot of boilerplate. Why?
When a simple change is anticipated in Redux, a lot of code is involved for enabling the changes. Let’s say we need to add a variable to the state. In any other application, the maximum code changes could be in one or two files. But, in Redux, the state needs to be updated in a large number of files repeating the code numerous times.
You will need to include all the below-mentioned steps for updating the state.
When we have one strong reason to avoid Redux which is that it increases the boilerplate code, another reason to add to it is that Redux is difficult to master.
When React was still in its nascent stage, Redux was introduced by Dan Abramov and Andrew Clark in 2015 in just two years after the React launch. Redux was primarily introduced by observing the loopholes in React’s state management system.
But, Redux was started being used more like a tradition than understanding its necessity. Soon, the developers began to bow down to the stress. Around the same time, React 16.3 version was released with a major upgrade onboard.
So, what happened until then?
As already mentioned, Redux did not have an organised way to pass down the state from the parent component to the children components. If a component needs the data, the state that is being called from the parent is being passed down through multiple levels unnecessarily. What’s more, the sibling or sidewise sharing of the state was not possible.
Now, this was essentially why Redux was introduced.
However, React in itself was improvised to overcome the state-sharing issue. The introduction of Context API changed everything.
The React Context is more like sharing the data that is declared as ‘global’ by different components in the application.
With the introduction to Redux Toolkit and hooks in the recent React versions, the Redux usage did dimmish to a certain extent.
This brings us to the question of when to use Redux and when not to use it.
Redux was primarily invented to make state management easier. But, in the process, it also makes the debugging part simpler. What happens in large applications is that there are a lot of programmers handling multiple lines of code. Debugging of the application state becomes a painstaking process when no one has any idea where the state is residing.
But, in Redux state changes are transparent due to the following reasons:
But, as mentioned in the earlier section, using Redux increases the boilerplate. Moreover, Redux is also difficult to learn.
So, the million-dollar question is, in this context, do we need Redux?
Most of the React applications are truly simple and straightforward. They have very few global states that need to be shared across components. Besides, a majority of times, you do not need to make the state globally available as there might be only a single component that might be interested in the state.
Also, even when the state has to be shared across different components, only a certain part of the application might need the state. In that context as well, the state need not be global.
But, when the state does need to be global, that’s when React Context API takes over, thus, mitigating the need to integrate with Redux.
So, does this mean that using Redux is redundant? Using Redux still holds water. Redux is still a great product with impressive and well-maintained documentation.
One of the best use cases for using Redux is when data fetching is all too frequent that needs a lot of cascading network communication. You might say, the cascading network communication is more of the backend development at play, however, there are instances when it becomes a part of front-end development. Redux is especially handy in such scenarios.
Another use case could be that of interdependent states. When a state is derived from other state information. While React is also capable of handling such situations, Redux can easily enable sharing, reusing, and reasoning.
There might be instances when real-time applications need web socket usage or analytics-based trading can be good examples where Redux can get around.
We will leave the other alternatives to Redux to our next blog and check if Redux stands out in the comparison.
With React upgrading to better state management with Context API and React Hooks, the need for implementing Redux has reduced substantially. However, Redux continues to offer a simplified solution to complex React applications. The developers should be able the differentiate between the best-suited Redux applications and when not to use Redux, which is when they will be able to reap the benefits accordingly.
