React useContext Hook

In the last lesson you learned about the React useCallback Hook, so your functions stay stable across renders. This lesson meets useContext, the hook that lets any component read shared data directly, no matter how deep it sits, with no prop drilling through the middle.

🤔 Why do we need useContext?

Here’s the pain. Some data is needed in many places, like the logged-in user, the theme, or the language.

• A value like the current theme is needed by buttons, headers, and cards all over the tree.
• To get it from the top down to a deep button, you thread it through every component in between.
• Those middle components don’t use the theme at all, they just forward it.
• Add one more value to share and you repeat all that drilling again.

So useContext is about reaching shared data directly. You put the value in a Context, and any component inside can pull it out, skipping every level in between.

🧩 The three pieces of context

Context always has the same three parts, and once you see them together the whole thing clicks.

• Create the context with createContext. This makes the shared “box”.
• Wrap part of your tree in the context’s Provider and give it a value. Everything inside can now read that value.
• Read the value anywhere inside with useContext(TheContext).

So the flow is: create, provide at the top, read at the bottom. The middle components do nothing.

💡 A simple example

Let’s share a theme without drilling. We create a context, provide a value at the top, and read it in a deep child.

import { createContext, useContext } from "react";

// 1. create the context with a default value
const ThemeContext = createContext("light");

function App() {
  // 2. provide a value to everything inside
  return (
    <ThemeContext.Provider value="dark">
      <Page />
    </ThemeContext.Provider>
  );
}

function Page() {
  // Page does NOT need the theme - it just renders a deep child
  return <Toolbar />;
}

function Toolbar() {
  // 3. read the value directly, no props passed in
  const theme = useContext(ThemeContext);
  return <button className={theme}>Current theme: {theme}</button>;
}

Follow the value from top to bottom.

• createContext("light") makes the box, with "light" as the fallback if no provider is found.
• ThemeContext.Provider value="dark" wraps the tree and sets the shared value to "dark".
• Page is in the middle and gets no theme prop. It just renders Toolbar.
• Toolbar calls useContext(ThemeContext) and gets "dark" straight from the provider.

A button reading: Current theme: dark

🔍 What useContext actually does

The hook itself is the easy part, so let’s see its one job.

• You call useContext(SomeContext) and pass the context object you created.
• It returns the current value from the nearest matching Provider above this component.
• When that provider’s value changes, every component reading it re-renders with the new value.
• If there’s no provider above, it returns the default you gave to createContext.

So useContext is just the “read” step. The provider decides the value, and the hook hands it to whoever asks.

🌍 Where context is a good fit

Context shines for data that many components need but that changes rarely, so use it for the truly shared, app-wide things.

• The current theme, like light or dark mode.
• The logged-in user and whether they’re signed in.
• The chosen language for an app that supports many.
• App-wide settings that lots of screens read.

So if a value is needed all over and would otherwise be drilled through many layers, that’s a strong sign context fits.

⚠️ Common Mistakes

The most common slip is reading a context with no provider above it, so you silently get the default.

// ❌ no <ThemeContext.Provider> anywhere above, so this is always the default
const theme = useContext(ThemeContext); // "light", even if you expected "dark"

// ✅ make sure a Provider wraps the component that reads it
<ThemeContext.Provider value="dark">
  <Toolbar /> {/* now useContext here gets "dark" */}
</ThemeContext.Provider>

Watch out for these.

• Don’t forget the Provider. Without one above, useContext returns the default, which feels like a bug that isn’t.
• Don’t put everything in one giant context. When its value changes, every reader re-renders. Split unrelated data into separate contexts.
• Don’t use context for fast-changing local state. A value that changes many times a second is better as local state, not shared context.

✅ Best Practices

A few habits keep context tidy and predictable.

• Use context for app-wide data that many components read, like theme, user, or language.
• Keep separate concerns in separate contexts, so a change in one doesn’t re-render readers of the other.
• Always wrap the components that read a context in its Provider.
• For data needed by only a couple of nearby components, plain props are simpler than context.

🧩 What You’ve Learned

• ✅ useContext lets any component read shared data directly, skipping every level in between
• ✅ Context has three pieces: createContext, a Provider with a value, and useContext to read it
• ✅ useContext(SomeContext) returns the value from the nearest Provider above the component
• ✅ When the provider’s value changes, every reader re-renders with the new value
• ✅ With no provider above, you get the default passed to createContext
• ✅ It’s a great fit for theme, user, and language, but not for fast-changing local state

🚀 What’s Next?

Now you can share data across your whole app without drilling props through every layer. Next you’ll learn how to bundle your own hook logic into a reusable function, so you can package and share behavior just like React’s built-in hooks.

React Custom Hooks