React Context API: Avoid Prop Drilling

Why it exists

In large React apps, passing state from a top-level component to a deeply nested one requires forwarding props through every intermediate component. This is called 'prop drilling' and it makes code verbose, hard to refactor, and tightly coupled. The Context API was created to solve this by providing a direct channel for data.

The mental model

Think of Context as a dedicated broadcast channel for a component tree. A special 'Provider' component acts as the transmitter, holding the value. Any component within its broadcast range can 'tune in' using the useContext hook to receive that value directly, without any components in between needing to know about it.

How it works

The process has three steps. First, you create a context object by calling createContext() outside any component, providing an optional default value. This default is a fallback for when a component tries to access the context without a Provider above it. Second, you wrap a part of your component tree with the context's Provider component, passing the data you want to share via its value prop. For example: <ThemeContext.Provider value={theme}>. Third, in any child component that needs the data, you call the useContext hook with the context object to read the current value, like so: const theme = useContext(ThemeContext);.

When to use it

Use Context for state that is considered 'global' for a tree of components and doesn't change frequently. This is perfect for data like UI theme (dark/light mode), the current authenticated user's information, application-wide settings, or a selected language. The key is that the data is needed in many places at different levels.

When not to use it

Avoid using Context for state that changes often, like form inputs or animation values. Every time the context value updates, all components that consume that context will re-render by default. For complex state management or high-frequency updates, dedicated state management libraries like Redux or Zustand are often a better choice as they offer more performance optimizations.

One canonical example

A simple theme switcher. Create a ThemeContext with a default of 'light'. In your root App component, use useState to manage the theme state ('light' or 'dark'). Wrap your application in <ThemeContext.Provider value={theme}>. A deeply nested Button component can then call useContext(ThemeContext) to get the current theme and apply the correct style, without any components in between needing to pass the theme prop.