As a React app grows, you'll inevitably run into the 'prop drilling' problem: data needed by a deeply nested component has to be passed as a prop through every intermediate component along the way, even ones that never use that data themselves.

This makes components harder to reuse and refactor, since changing what a deeply nested child needs means touching every component in between just to forward the value along.

The Context API lets you pass data through the component tree without manually threading it through props at every level — it's essentially a global state mechanism built directly into React. Any component inside a context's tree can read the value directly, regardless of how deeply it's nested.

Context is best suited for data that's genuinely global to a subtree, like the current theme, the logged-in user, or the active language — not for data only a couple of nearby components need.

The first step in using Context is creating a context object with createContext, for example export const ThemeContext = createContext('light'). The argument you pass is the default value used if a component reads the context without any Provider above it in the tree.

This is typically done outside of any component, often in its own file, so both the component that provides the value and every component that consumes it can import the same context object.

Every context object comes with a <Provider> component. To actually share a value, wrap the highest-level component that needs access to it with <ThemeContext.Provider> — every component nested inside that Provider, no matter how deep, gains access to the shared value.

Components outside the Provider simply can't read the context at all, which is why the Provider is usually placed near the root of the tree, often wrapping the whole app.

The Provider component accepts exactly one meaningful prop: value. Whatever you pass into value — a string, an object, an array of state variables, anything — is exactly what gets broadcast to every component consuming that context underneath it.

For example, <UserContext.Provider value={{ name: 'Alice' }}> makes that object available to any descendant that reads UserContext, without it ever being passed down as an explicit prop.

To actually read context data deep inside the tree, a component calls the useContext hook, passing in the context object it wants to read: const theme = useContext(ThemeContext). It returns whatever value the nearest matching Provider above it is currently broadcasting.

There's no need to pass anything else — useContext automatically walks up the tree to find the closest Provider for that specific context object and subscribes the component to its value.

Context is reactive: whenever the value prop passed to a Provider changes, React automatically re-renders every single component consuming that context via useContext, no matter how deeply nested each one is.

This is what keeps a global theme or auth state in sync everywhere at once — change the value at the Provider, and every consumer picks up the new value on its next render without any manual wiring.

Context by itself is just a broadcast pipe — it doesn't hold any dynamic state on its own. To make it dynamic, combine it with useState or useReducer inside the component that renders the Provider, then pass both the current value and its setter down through value, e.g. <ThemeContext.Provider value={{ theme, setTheme }}>.

Any consumer can then destructure { theme, setTheme } from useContext(ThemeContext), read the current value, and call setTheme to update it for the whole tree at once.

It's completely normal for a larger application to need multiple contexts at once — one for theme, one for authentication, one for a shopping cart, and so on. Each should stay separated by domain rather than merged into one giant catch-all context.

You combine them simply by nesting their Providers inside one another near the root of the app, such as <AuthProvider><ThemeProvider><App /></ThemeProvider></AuthProvider>, giving App and everything inside it access to all of them.

A common professional pattern is wrapping useContext in a dedicated custom hook, like useTheme(), instead of forcing every consuming component to import both useContext and the raw context object directly.

This hides the implementation detail and lets the hook throw a helpful error — if (!context) throw Error('Must be in ThemeProvider') — if a developer forgets to wrap part of the tree in the corresponding Provider, catching the mistake early instead of failing silently.

Context has a real performance downside: because every value change re-renders ALL consumers, it's a poor fit for high-frequency updates like mouse coordinates or a timer ticking every 16 milliseconds — every consumer would re-render on every tick.

Good use cases are low-frequency global state like the logged-in user, dark mode, or the active language. For fast-changing, localized state, prefer plain useState in the component that needs it, or a dedicated state library.

You now have the core toolkit for global state in React: creating a context, wrapping a subtree in its Provider, broadcasting a value (optionally combined with useState for dynamic updates), reading it anywhere with useContext, and wrapping that in a clean custom hook.

With Context handled, the next step is learning to build your own reusable custom hooks that encapsulate logic beyond just context — a pattern used throughout production React codebases.

The Prop Drilling Problem. Welcome to Global Context. As your React applications grow, you'll inevitably encounter the 'Prop Drilling' problem. This happens when you need to pass data from a high-level component down to a deeply nested child, forcing you to pass the prop through many intermediate components that don't actually need it.

What is Context?. The React Context API provides a way to 'teleport' data through the component tree without having to pass props down manually at every level. It's essentially a global state management tool built directly into React. It is perfect for things like themes, user authentication data, or language settings.

createContext(). The first step is to actually create a context object using createContext. You typically do this outside of your components, often in a separate file, so that it can be imported by both the component that provides the data and the components that consume it.

The Provider Component. Every Context object comes with a <Provider> React component. To share the data, you wrap the highest-level component that needs the data with this Provider. Any component inside the Provider (no matter how deeply nested) will be able to access the context.

If you want the entire application to have access to the UserContext, where should you place the <UserContext.Provider>?

• →Inside the lowest leaf component
• →At the very top, wrapping the <App /> component

Providing the Value. The Provider component accepts exactly one prop: value. Whatever you pass into this value prop is what will be broadcasted to all the components inside it. It can be a simple string, an object, or even an array of state variables.

The Consumer: useContext. To actually read the data deep inside your component tree, you use the useContext hook. You import the Context object you created earlier, pass it to useContext, and it instantly returns whatever value the nearest Provider is broadcasting.

What argument do you pass to the useContext hook?

• →The Context object itself (e.g., ThemeContext)
• →A string with the context name (e.g., 'Theme')

Context Updates. The true power of Context is its reactivity. Whenever the value prop passed to the Provider changes, React will automatically re-render EVERY component that is consuming that context via useContext. This ensures your UI is always in sync with the global state.

Dynamic Context (with useState). Context itself doesn't hold dynamic state; it just broadcasts it. To make a dynamic context, you combine it with useState or useReducer inside the component that renders the Provider. You then pass both the state variable and the setter function in an object down through the value prop.

If you pass an object { user, setUser } to the Provider's value, how does a deeply nested child update the user?

• →It calls the setUser function received from the context
• →It modifies the user object directly

Nesting Contexts. It is perfectly normal and expected to have multiple Contexts in a large application. You should keep them separated by domain (e.g., one for Theme, one for Auth). You simply nest the Providers inside each other at the root of your application.

Custom Context Hooks. A professional pattern is to create a 'Custom Hook' for your context. Instead of forcing every component to import useContext AND ThemeContext, you create a useTheme() function. This hides the complexity and allows you to throw a helpful error if the developer forgot to wrap the app in the Provider.

When NOT to use Context. Context is powerful, but it has a downside: performance. Because it re-renders ALL consumers when the value changes, it is terrible for high-frequency updates like tracking mouse coordinates or a timer that ticks every 16ms. Use it for low-frequency global state (auth, themes). For high-frequency state, use local useState or specialized libraries like Zustand or Redux.

Mastery Achieved. Context mastery achieved! You now know how to architect global state systems. You understand Providers, Consumers, how to combine Context with state hooks, and when to avoid it for performance reasons. Next up: building your own Custom Hooks!