What Is Redux (And Why Component State Falls Apart)
Redux solves the prop drilling problem by moving state outside React components into a centralized store any component can read directly.
React's component model is clean until it isn't.
Every component owns its state and passes data to its children via props. For isolated, self-contained components, that model is perfect. The second you need the same piece of data in two places that aren't in a direct parent-child line, the model starts to fight you.
Redux exists because that problem gets worse every time your application grows.
The Wall You Hit with Component State
Picture a social feed app. The rough component structure:
<App>
├── <Navbar />
├── <Feed />
│ └── <Post />
│ └── <LikeButton />
└── <Sidebar />
└── <ProfileCard />Now imagine currentUser: the logged-in person's data. <Navbar> needs it to show their avatar. <LikeButton> needs it to check if they already liked the post. <ProfileCard> needs it to display their details.
Where does currentUser live?
The React answer: lift it up to the nearest common ancestor. <App> becomes the owner and passes currentUser down via props.
That works. Here is what it actually looks like.
<Feed> doesn't need currentUser for itself, but it has to accept it as a prop and pass it to <Post>. <Post> doesn't need it either, but it has to pass it to <LikeButton>. The data tunnels through components that have zero use for it, purely because they sit between the owner and the consumer.
This is prop drilling.
In a real application with five levels of nesting and thirty pieces of shared state, this becomes genuinely unmanageable. Every new requirement means tracing which ancestor needs to own which piece of state, then threading it down through every intermediate component whether they need it or not.
The secondary problem is visibility. When currentUser changes somewhere, which component caused it? Which chain of re-renders triggered? With component state spread across a tree, there is no centralized log. You are tracing threads through a maze every time something goes wrong.
What Redux Does Instead
Redux moves state outside the component tree entirely.
Instead of any component "owning" the data, that data lives in a Redux store: a single object that exists independently of your React components. Any component in the application can read from that store directly. No prop chains. No intermediate carriers.
ExpandProp drilling vs Redux store
<Navbar> reads from the store. <LikeButton> reads from the store. <ProfileCard> reads from the store. <Feed> and <Post> are completely untouched. They never needed that data and now they never have to pretend they do.
The state is global, not owned.
That single shift removes the entire prop drilling problem. No component is responsible for ferrying data to another component. The store is simply there, and anything that needs it reads it directly.
The Real Tradeoffs
Redux solves the sharing problem. It also introduces new ones.
The learning curve is steep at the start. You will encounter terms: store, action, action creator, reducer, dispatch. These have precise meanings in Redux and do not map cleanly to anything in vanilla React. The first few times you wire up a full Redux flow, it feels like writing an enormous amount of code to do something simple.
That complaint is valid.
Redux has boilerplate. For a small application with three screens and mostly local state, Redux is absolutely the wrong tool. The React docs themselves say to reach for simpler solutions first. Learning the hooks primitives deeply makes Redux much easier to reason about later.
For large applications with dozens of screens, multiple teams, and complex state that needs tracking and auditing, the boilerplate pays for itself:
- Centralized state: any component reads what it needs without prop chains
- DevTools: every state change is logged, replayable, and inspectable in the browser extension
- Predictable updates: state can only change through explicit actions, so nothing is ever modified by surprise
- Selective re-renders: components only re-render when the specific slice of state they subscribe to actually changes, not on every update
- Middleware: async operations, logging, and analytics layer in without touching business logic
Redux adds complexity upfront in exchange for maintainability later.
Where Redux Fits
Redux is not the only solution. Zustand and Jotai offer much lighter alternatives with less ceremony. React Context combined with useReducer handles many patterns without any external library. Redux Toolkit, the modern way to write Redux, removes most of the manual boilerplate.
But Redux remains the most widely deployed state management solution in production React codebases by a wide margin. Understanding it means you can contribute to a huge proportion of existing applications without friction.
And it comes up in interviews constantly. Knowing it is not optional for senior React roles.
The right question is not "should I learn Redux." It is "when does my application actually need it." Use it when shared state grows complex enough that prop drilling becomes a maintenance problem. Skip it when your components are mostly self-contained.
Next up: the data flow model inside Redux. One direction, always. And why that constraint is the whole point.
The Essentials
- Redux is a state management library that moves state out of React components into a centralized store, making that state globally accessible to any component without prop drilling.
- The prop drilling problem is what happens when components must pass data through intermediaries that don't need it. The deeper the tree, the worse it gets.
- The tradeoff is real: Redux adds boilerplate and a learning curve upfront in exchange for predictable, traceable, globally accessible state. Worth it for large apps, unnecessary for small ones.
Further Reading and Watching
- Redux Motivation: the official explanation of the exact problem Redux was designed to solve
- Redux in 100 Seconds: Fireship's fast visual walkthrough of how Redux works
Keep reading