Context & Prop Drilling
The problem
Some data (the current theme, the logged-in user) is needed by components scattered throughout the tree at very different depths, and passing it down as props through every intermediate component that doesn't even use it directly clutters the whole component tree with pass-through plumbing.
Why now
Props and composition already established the normal way data flows — explicitly, parent to child. Context is the deliberate escape hatch from that rule for genuinely widely-needed data, and understanding why it's an escape hatch (not the default) requires already valuing props' explicitness.
Mental model
Prop drilling is threading a value through five components that don't care about it, just so the sixth one can use it. Context skips the threading entirely — a provider makes a value available to the whole subtree below it, and any descendant can read it directly, at the cost of that data flow no longer being visible in the component's own prop signature.
Requires
- Props & CompositionReact
Context is explicitly presented as the alternative to passing data via props through every intermediate level; you need to feel prop drilling's pain firsthand — via props-and-composition's normal data flow — before context's tradeoff is legible.
Used in
- Theme providers (dark/light mode) available anywhere in the app
- Authentication state (current user) needed across many unrelated components
- Internationalization/localization data threaded through an entire app
- State management libraries that build more scalable patterns on top of or instead of raw Context
Projects
- Build a small app that drills a 'currentUser' prop through four levels of components, then refactor it to use Context and compare the resulting code
- Identify a real scenario where Context would be overkill compared to just passing a prop one or two levels, and explain the tradeoff
Examples
- A five-level-deep Avatar component needing currentUser without Context requires passing currentUser as a prop through four components that never use it themselves
- A ThemeContext.Provider wrapping the whole app lets any deeply nested component read the current theme with useContext(ThemeContext), no drilling required
Resources
Mastery checklist
- I can identify prop drilling in a real component tree
- I can refactor a prop-drilled value into Context
- I can explain the tradeoff Context makes (implicit data flow) versus explicit props
- I can judge when a value is 'widely needed enough' to justify Context over props