Lesson 5 — Context, and when not to use it

Context lets a component read a value provided by an ancestor at any depth, without every component in between passing it along. The intermediate components never mention it.

In your language

Context is a ContextVar, or a value bound for the duration of a request. It is dynamic scoping: the value depends on where in the tree you are called from, not on what you were passed. Everything good and everything dangerous about it follows from that.

The three moving parts

src/contexts/ThemeContext.tsx

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

type Theme = 'light' | 'dark'

// 1. CREATE — the default is used only when there is no Provider above.
const ThemeContext = createContext<Theme>('light')

// 3. CONSUME — wrapped in a custom hook, which is the convention.
export function useTheme() {
  return useContext(ThemeContext)
}

// 2. PROVIDE
export function ThemeProvider({ children }: { children: React.ReactNode }) {
  const [theme] = useState<Theme>('dark')

  return (
    <ThemeContext value={theme}>
      {children}
    </ThemeContext>
  )
}

Version note In React 19 you render the context itself: <ThemeContext value={x}>. Older code — and most tutorials — writes <ThemeContext.Provider value={x}>. Both work; you will see both. Do not let it confuse you.

Wrap the tree once:

<ThemeProvider>
  <App />
</ThemeProvider>

And any descendant, at any depth, reads it with no props involved:

export function Avatar() {
  const theme = useTheme()
  return <div className={theme === 'dark' ? 'bg-slate-800' : 'bg-white'} />
}

The rule for when to use it

Context suits data that is genuinely global to a subtree, read in many places, and changes rarely. The canonical list is short, and that shortness is the point:

Good fit	Why
Theme / locale	Read everywhere, changes almost never.
Signed-in user	Read in many places, changes on login/logout.
Routing state	Same shape — which is why the router provides it for you.

Bad fit	Why
Form field values	Change on every keystroke. Every consumer re-renders on every keystroke.
Server data (lists, records)	Needs caching, loading and error states, refetching. That is TanStack Query's job, not Context's.
State two siblings share	Lift it to their parent. Context here is a sledgehammer.
"It saves me passing a prop"	Not a reason. That is what props are.

What it actually costs

Context is not free, and the costs are not obvious until they bite:

Every consumer re-renders when the value changes. Not just the ones using the changed field — the whole value is one unit. A context holding { user, theme, sidebarOpen } re-renders every consumer whenever the sidebar toggles.
You lose the dependency graph. With props, the type signature tells you what a component needs. With context, a component can depend on something invisible from its call site. Refactoring gets harder, and so does testing — the component now needs a Provider to render at all.
It hides coupling rather than removing it. The dependency did not disappear; it stopped being written down.

A search box's text is needed by a results list two levels below it. Best solution?

The decision, in order

Pass props. Two or three layers is fine — stop worrying about it.
Restructure with children so the middle layers do not see the data. Most drilling complaints end here.
Only then, Context — and only for wide, rarely-changing values.
Server data is a different problem. Reach for TanStack Query, not any of the above.

Exercise

Two halves; the second matters more than the first.

A — build it. Add a ThemeContext to the task app with a working light/dark toggle. The toggle button lives in a header; the task rows read the theme and change colour. Note that no component between the provider and a task row mentions the theme.

B — argue against it. Then add a second context holding tasks and toggleTask, so TaskRow can stop taking props entirely. It will work. Now write three or four sentences on what you gave up. Bring them to Martin.

Have a go at B's answer before revealing.

TaskRow's props no longer describe what it needs — its real dependency became invisible.
It can no longer be rendered without a provider, so tests and reuse both get harder, and it can never show a task from a different list.
Every consumer re-renders whenever any task changes.
Nothing was actually gained: the data was one level away. There was no drilling to remove.

This is the exercise. The skill being built is declining to use context, which is harder than using it.

Ask Martin. Ask which contexts exist in the real codebase and why each one earned its place. Then take the disagreement you are most unsure about to Reactiflux or r/reactjs — "when is context the wrong tool" is a question practitioners argue about productively, and the argument is where the judgement comes from.

Context, and when not to use it

The three moving parts

The rule for when to use it

What it actually costs

Exercise

Read this next — primary source

Reference

Next