Difficulty: Intermediate
How does React Context API work? What are its performance implications and how do you optimize it?
Let's have an honest conversation about the Context API, because it's one of those things that people either misunderstand or overuse, and both lead to problems.
At its core, the Context API solves one specific problem: prop drilling. Prop drilling is when you need to pass data from a top-level component through many intermediate components that don't actually use the data, just to get it down to a deeply nested child that does. For example, imagine passing a 'theme' prop from App through Header through Navigation through NavItem just so NavItem can change its color. Every component in the chain has to accept and forward that prop even though most of them don't care about it. That's annoying, error-prone, and clutters your component signatures.
Context lets you create a direct tunnel between the provider (the component that has the data) and the consumers (the components that need it), bypassing all the intermediate components entirely.
Here's how it works in practice. You call createContext to create a context object. Then you wrap a section of your component tree with a Provider component that supplies a value. Any component inside that tree can call useContext to read the current value, no matter how deeply nested it is. The intermediate components don't need to know anything about the context.
Now, here's where it gets tricky, and this is the part that trips up a lot of developers: Context is NOT a state management tool. It's a dependency injection mechanism. It doesn't manage state by itself. You still need useState or useReducer to actually hold and update the state. Context just makes that state available to distant components without passing it through props. This distinction matters because people often compare Context to Redux or Zustand, but they're solving different problems.
Let's talk about the performance gotcha, because this is what interviewers really want to hear about. When a Provider's value changes, every single component that consumes that context re-renders. Not just the ones that use the specific piece of data that changed, ALL of them. And here's the sneaky part: if you pass an object literal as the provider value, like value={{ user, theme, notifications }}, you're creating a brand-new object on every render (because {} !== {} in JavaScript). That means every consumer re-renders every time the provider's parent re-renders, even if none of the actual data changed.
This is devastating for performance. Imagine you have a single AppContext with user data, theme preferences, notification count, and sidebar state. The notification count updates every few seconds. With a single context, your theme toggle button, user avatar, sidebar, and every other consumer will re-render every time the notification count changes, even though they don't use notifications at all.
So how do you fix this? There are three main strategies:
1. Split your context into multiple smaller contexts. Instead of one giant AppContext, create ThemeContext, UserContext, NotificationContext, etc. Now when the notification count changes, only components consuming NotificationContext re-render. The theme toggle only re-renders when ThemeContext changes. This is the most impactful optimization.
2. Memoize your provider value with useMemo. Wrap the value object in useMemo so it only creates a new reference when the actual data changes, not on every parent render. This prevents unnecessary re-renders caused by the parent re-rendering for unrelated reasons.
3. Separate state from dispatch. This is a clever pattern where you create two contexts: one for the state (which changes) and one for the dispatch function (which is referentially stable). Components that only need to trigger actions (like a button that adds a todo) consume only the dispatch context, so they never re-render when the state changes. Components that need to display data consume the state context.
Let me give you a real-world scenario. Say you're building a todo app with Context. You have a TodoProvider that holds the todo list and a dispatch function from useReducer. If you put both in the same context, your AddTodo form re-renders every time any todo is toggled or deleted, because the state context value changed. But the form doesn't display todos. It only needs dispatch to add new ones. By splitting into TodoStateContext and TodoDispatchContext, the form only re-renders when dispatch changes (which is never, since dispatch from useReducer is stable). The todo list component consumes both contexts, which is fine because it needs to display the actual todos.
Some important things to know:
- The default value you pass to createContext is only used when a component tries to consume the context but there's no Provider above it in the tree. In most apps this is an error, so some people pass null as the default and throw an error in a custom hook if the context is null.
- Context providers can be nested, and the closest provider wins. This lets you override values for specific subtrees. For example, you could have a global ThemeContext providing 'light', but wrap a specific section of your app in another ThemeProvider with 'dark'.
- Context is great for things that change infrequently and are needed by many components: auth state, theme, locale, feature flags. It's NOT great for rapidly updating data like form inputs, drag positions, or animation values. For those, use local state, Zustand, or other specialized state management.
- In React 19, the new use() hook will let you consume context with a simpler syntax, and it can be used inside conditions, which useContext cannot.
The bottom line: Context is a powerful tool when used correctly, but it's not a silver bullet. Know its limitations, split your contexts, memoize your values, and reach for external state management when Context isn't the right fit.
const AppContext = createContext(null);
function AppProvider({ children }) {
const [user, setUser] = useState(null);
const [theme, setTheme] = useState('light');
const [notifications, setNotifications] = useState([]);
// BUG: New object on every render = ALL consumers re-render
return (
<AppContext.Provider value={{
user, setUser, theme, setTheme, notifications, setNotifications
}}>
{children}
</AppContext.Provider>
);
}
// This component re-renders when notifications change
// even though it only uses theme!
function ThemeToggle() {
const { theme, setTheme } = useContext(AppContext);
console.log('ThemeToggle rendered!'); // Too often!
return (
<button onClick={() => setTheme(t => t === 'light' ? 'dark' : 'light')}>
{theme}
</button>
);
}Putting everything in one context means every consumer re-renders on any change. The value object is recreated every render, triggering all consumers.
// Split into focused contexts
const ThemeContext = createContext('light');
const UserContext = createContext(null);
function ThemeProvider({ children }) {
const [theme, setTheme] = useState('light');
// Memoize the value to prevent unnecessary re-renders
const value = useMemo(() => ({ theme, setTheme }), [theme]);
return (
<ThemeContext.Provider value={value}>
{children}
</ThemeContext.Provider>
);
}
function UserProvider({ children }) {
const [user, setUser] = useState(null);
const value = useMemo(() => ({ user, setUser }), [user]);
return (
<UserContext.Provider value={value}>
{children}
</UserContext.Provider>
);
}
// Compose providers
function AppProviders({ children }) {
return (
<ThemeProvider>
<UserProvider>
{children}
</UserProvider>
</ThemeProvider>
);
}
// Now ThemeToggle only re-renders when theme changes
function ThemeToggle() {
const { theme, setTheme } = useContext(ThemeContext);
return <button onClick={() => setTheme(t => t === 'light' ? 'dark' : 'light')}>{theme}</button>;
}Splitting contexts ensures components only re-render when their specific context changes. Memoizing the provider value prevents re-renders from parent updates.
const TodoStateContext = createContext(null);
const TodoDispatchContext = createContext(null);
function todoReducer(state, action) {
switch (action.type) {
case 'ADD': return [...state, { id: Date.now(), text: action.text, done: false }];
case 'TOGGLE': return state.map(t => t.id === action.id ? { ...t, done: !t.done } : t);
case 'DELETE': return state.filter(t => t.id !== action.id);
default: return state;
}
}
function TodoProvider({ children }) {
const [todos, dispatch] = useReducer(todoReducer, []);
return (
<TodoStateContext.Provider value={todos}>
<TodoDispatchContext.Provider value={dispatch}>
{children}
</TodoDispatchContext.Provider>
</TodoStateContext.Provider>
);
}
// This component only needs dispatch - never re-renders on state changes!
function AddTodo() {
const dispatch = useContext(TodoDispatchContext);
const [text, setText] = useState('');
return (
<form onSubmit={e => {
e.preventDefault();
dispatch({ type: 'ADD', text });
setText('');
}}>
<input value={text} onChange={e => setText(e.target.value)} />
<button type="submit">Add</button>
</form>
);
}
// This component reads state and re-renders appropriately
function TodoList() {
const todos = useContext(TodoStateContext);
const dispatch = useContext(TodoDispatchContext);
return (
<ul>
{todos.map(todo => (
<li key={todo.id} onClick={() => dispatch({ type: 'TOGGLE', id: todo.id })}>
{todo.done ? 'Done' : 'Todo'}: {todo.text}
</li>
))}
</ul>
);
}By separating state and dispatch contexts, components that only dispatch (like forms or buttons) never re-render when state changes. Dispatch is referentially stable.
Context API, Provider, Consumer, Performance, Splitting Context