Managing Global State with Context

You can now move shared state to a common parent in the React for Beginners series — but what about state that every component needs? The current user, the colour theme, the selected locale. Passing those through fifteen layers of props is called prop drilling, and it makes unrelated components depend on each other. React's built-in answer is Context: a way to publish a value that any component can read without explicit prop chains.

The prop drilling problem

Suppose the theme lives in App but a deeply nested footer needs it. Without context, every component in between must forward the prop, whether it uses it or not:

<App theme={theme}>
  <Page theme={theme}>
    <Section theme={theme}>
      <Footer theme={theme} />   {/* every layer must cooperate */}
    </Section>
  </Page>
</App>

Expected output: a working footer — but Page and Section now both depend on a prop they never use, and inserting a new layer breaks them all.

createContext and Provider

Context has three moving parts: create it, provide a value, consume it. First, create the context once at module scope:

import { createContext, useContext, useState } from 'react';

const ThemeContext = createContext(null);   // default value: null

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');
  const toggle = () => setTheme((t) => (t === 'light' ? 'dark' : 'light'));

  return (
    <ThemeContext.Provider value={{ theme, toggle }}>
      {children}
    </ThemeContext.Provider>
  );
}

The provider wraps your tree (usually near the root) and owns the state. Everything below it can read the current value without receiving it as a prop.

useContext: reading from anywhere

Any descendant calls the useContext hook with the context object and gets the provider's current value:

function ThemeToggle() {
  const { theme, toggle } = useContext(ThemeContext);
  return (
    <button onClick={toggle}>
      Theme is {theme} — click to switch
    </button>
  );
}

Expected output: clicking the button flips every consumer — toggle, page, footer — in one update, because they all read the same state. No layer in between heard anything about it.

The full picture

What belongs in context (and what does not)

Context solves low-frequency, widely-shared data. Use it well by choosing carefully:

• Good fits — theme, current user, locale, feature flags, router state.
• Bad fits — a search box value used by two siblings (lift state instead), fast-changing counters, large lists that re-render everything on each keystroke.
• Not a state manager — context publishes values; it does not memoise, cache or batch for you. Heavy apps layer libraries (Redux, Zustand, TanStack Query) on top, often still using context for the last mile.

Because every consumer re-renders when the provider's value changes, keep the value stable — build it with useMemo when it is an object or function (see chapter 18), and split independent values into separate contexts so a theme change does not re-render user-dependent UI.

Custom consumer hooks

A tidy convention wraps the lookup in a named hook, centralising the null check and simplifying call sites:

export function useTheme() {
  const ctx = useContext(ThemeContext);
  if (!ctx) throw new Error('useTheme must be used inside ThemeProvider');
  return ctx;
}

// anywhere below the provider:
const { theme, toggle } = useTheme();

Expected output: a clear error — "useTheme must be used inside ThemeProvider" — instead of a silent null crash when a component is misplaced. This hook also previews chapter 19: wrapping hook logic into named, reusable functions.

Provider composition

Providers are just components, so nesting them reads like a configuration list — auth inside theme inside router, or the reverse, depending on who needs whom:

<StrictMode>
  <ThemeProvider>
    <AuthProvider>
      <App />
    </AuthProvider>
  </ThemeProvider>
</StrictMode>

Common mistakes

• Creating context inside the component — every render makes a new context and consumers lose the provider; create it at module scope.
• Meaningful default values — a default of { theme: 'light' } silently masks a missing provider; default to null and throw.
• Context as the default state store — two sibling components that share data only need lifting, not a global.
• Unstable provider values — an inline object/array literal re-renders all consumers on every provider render; memoise the value.
• One giant context for everything — splitting by concern prevents unrelated updates from re-rendering the whole tree.

Practice checklist

1. Convert a drilled theme prop into ThemeContext + provider + useContext.
2. Remove the intermediate props and confirm the tree still updates everywhere.
3. Add a second context (current user) and verify theme changes do not re-render user UI.
4. Write a useTheme hook that throws outside its provider; trigger the error.
5. Memoise the provider value and check render counts in the DevTools profiler.

Global values solved — now give users multiple pages without full reloads: Routing with React Router.