Back then, I started using React Context in my web apps mainly for auth and session-related info/status.
The idea of Context is simple: it is created for the app (its components) so that prop drilling can be avoided, and the state can be easily accessed by the components that actually need it—while ensuring proper updates and usage of state data.
The React Context API (createContext, useContext, useState, etc.) worked well for me, and I’ve used it in many of my web apps (React + Next.js).
What I liked the most—and what I think many developers will find helpful—is how it eliminates prop drilling and helps in understanding the layout structure when using a Context Provider. I became quite comfortable with React Context.
But there is also another library designed for managing shared state and complexity: Redux.
Enter Redux
Using Redux requires understanding a few core concepts:
- Store
- Slices
- Reducers
- Actions
The Store, which is the global state container, is singular—there is only one store in an app. Inside it, you have multiple slices, where each slice represents a specific feature or concern and contains its state, reducers, and actions.
I’m not writing this article to teach Redux or deeply explore its internal structure. Instead, I’ll explain my thinking using an example from one of my projects.
A Real Project Example
I have an e-commerce-based Next.js web app called Nur Fashions. It’s a template-nature, client-based project.
In this project, I’m using React Context for:
- Authentication
- Cart management
- Location (for currency, etc.) From my experience, Context API is completely fine for these use cases.
Why?
- No complex backend involvement
- No heavy backend syncing
- No asynchronous workflows
- Fewer uncertain or branching operations
So for these parts of the app, React Context is more than enough—there is simply no need for Redux here.
Where Redux Makes Sense
However, one important process in this app is the ordering flow after cart checkout.
This process needs to be handled very carefully:
- It involves asynchronous operations with the backend
- It requires clearly defined and strongly typed states (loading, success, failure, etc.)
- It has the potential to grow in complexity and scalability, with more backend syncing and business logic added over time
For this reason, using Redux here felt both reasonable and professional. So I set up Redux (store + slice) and wrapped it with a provider in the layout.
A Key Realization
While working on this, I came across a very important professional insight:
Redux is NOT about lifetime. Redux is about complexity.
Before understanding this, I was more convinced of the idea that Redux should only be used for long-living context or global state. But now my perspective has changed.
What truly matters is how complex and scalable the state logic is, not how long the data lives.
And that, for me, is the real distinction between React Context and Redux.
Top comments (0)