This blog assumes you know how to use Redux and context API. And only want to know the differences between the two.
The why part will be brief cause I don't want this to become 3 blogs jammed into one but if you want more on why let me know.
why
Before I start with any new library/framework/language I like to get the answer for why it was made. So let answer that question before we get started.
Redux
why the need for redux? As you might know Redux is not a react specific library its framework agnostic. Although react community was the very first to embrace it cause it fits very nicely with the unidirectional data flow approach of reacting to change.
Redux implements the flux patter for managing state in an application and provide the state and menace to update it across the application where we need it.
Redux has 3 main components an Action a Reducer and a State
An action is just a plane object that has a type property and an optional payload by convention.
Type tells what kind of change we want and payload caries any additional data required to make that change
A reducer is a pure function that takes in the current state and computes the new state. It's just that simple.
The state is what our UI cares about we subscribe to the state or a subsection of state and update when it changes
Context API
Context API is used to share data between components in a react app and you can also share a function with which you can update the shared data.
You can use multiple contexts within the same app. Which not so each with Redux. Context API doesn't have clear instruction on how to achieve this objective. And depending upon the type of person you are you might like or dislike the hands-off approach of the context API
You might want to make a sharing strategy that best fits your application. There is no fancy chart for context API
why
Hey, why again. But this why is different this why is for
Why Redux vs Context API
I mean why even ask Redux vs context. As it turns out both are solving the same problem of data sharing. But both have different pros and cons. We will rank both in three categories.
- Learning curve
- Boiler Plate code
- Performance (the most important one) ### Learning curve
context has the smother learning curve between the 2. Cause it doesn't enforce a particular way of doing things so this one goes to context
So the score is
- Redux 0
- Context 1
Boilerplate
If you have ever read anything about Redux the only complain is the boilerplate code. so the score should be easy right? But the fact is the boilerplate is a one-time investment and it does bring a bit of structure when it comes to updating data. so let's call it even and give 0.5 to each
So the score by now is
- Redux 0.5
- context 1.5
Note
when I say performance I not only mean run time performance but a combination of runtime and write time performance. And sometimes gain in one means loss in another so we need to have a balance.
So now its performance. I wish the answer to this one were easy, but performance depends on many factors. One of the most important ones are
- App size
- Number of visible components at a time
The TL;DR is Redux for complex apps and Context for simpler apps
I can't give a simple answer regarding whats a simple app and what a complex app. But I will try to help you make how to judge if your app is simple enough for context or complex enough for redux
When
Now let's try and answer when is your app simple enough for context or complex enough that Redux is needed
When Redux
SO... when to use redux when is the additional complexity welcomed let dive in.
Now let's explain what the above diagram means.
I will explain it without making this post all about how redux works and how it causes react to re-render. So when using redux we can subscribe to the state or a peace/selection of the state and when the state or the selection of the state changes the subscribed component re-renders.
But what does that means? It means if your components are not subscribed to the store they won't re-render after a dispatch.
For example, Sidebar and Dashboard item is not subscribed to the store so they won't re-render when store updates simple enough
But if your component doesn't care about the part of the state that changed what then? If you see clearly we are not subscribing to the entire state but to a subset of the state (we can use the useSelection hook or connect HOC) our components will only update when the subset changes.
So now with that in mind if you have a lot of components simultaneously updating the global state where changes made by one component might not affect most of the other components. And you have lots and lots of those redux will give a performance edge (we will see why in a bit)
When Context
when to give up on redux and ignore some extra re-renders.
The same app but with context instead of redux now let's see how it will behave. When we change something in Nav the entire tree under the context provider will re-render the event if it's not using use context hook or context consumer HOC. This is indeed a performance hit and will cause unnecessary re-renders.
Now that might not a big issue depending on the app. For example, if most of the state is the local and global state is rarely updated (e.g auth state, theme state) context can be used in such a condition cause few unnecessary re-renders is not that big of an issue especially considering the ease of use and development brought by context API
About the last point as you see it not easy. So you can use the above method and see where that one point goes to for your app
Note
redux is not the only solution we can use some less popular solutions like mobx,xstate And the shiny new one recoil. Are the few that I know of
Conclusion
The summary would be use context when the app is small and simple but redux when the app is big and complex. Well, all apps start as small and simple and grow into a bigger and complex app what to do then? Answer to that will require an article to itself
Top comments (4)
Hi, I'm a Redux maintainer. The answer is not as simple as "Redux for complex apps, Context for simple apps". It's important to understand that Redux and Context are different tools that solve different problems.
I recently wrote a post called Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux), which is intended to be a definitive explanation for what the purposes and use cases are for each of these tools and when it makes sense to use them.
Nice article @markerikson , it very definitive on what is what. I have used redux in many projects & I quite like it. however one of the things that bugs me often is when I'm working on big project & there comes a scenario in which I want to store state with short life time and is only consumed by few components (eg. form with multiple steps) in such case it did not make that much sense to me to store this state in global state manager but at the same time I didn't want to store it in local state to avoid prop-drilling. for me this is where context usually comes in & taking the best of both makes things much easier. what I want to point out is there is a scenario in which Context fills Redux's shortcoming & vice versa hence in my opinion seeing the as one versus the other might not be valid point.
The reason why I choose to go with redux, when it comes to state management is because of it's maintainers. They're soo active and conscientious, that there's a solution to any potential issues that might come up.
Thank you guys!
With all due respect. I think I failed to get my point across in the why context and where context section. I know it's just a DI solution but since I planned this article for new developers I tried to not use such technical terms as dependency injection and such. Since most totorials teach context with useState and useReducer as state management solution I went with it