变式五 · 主题切换：Context 怎么用Variation 5 · theme switching: how to use Context

Earlier we said props flow down, events report up. That rule works nicely for two or three levels, but something like a theme has to be readable by the whole tree:

The components in the middle do not care about the theme at all, yet they are forced to take a theme and hand it further down. That is prop drilling. Add a toggleTheme and you drill it all over again.

What Context does is skip the middle: a Provider puts a value up top, and a component at any depth in the subtree reads it directly.

But do not use it as a state manager. The test is simple:

• Use it for things the whole tree reads that rarely change — theme, current user, language, route.
• Do not use it for something only two or three levels need (pass props); or for something that changes every second (when a context changes, every consumer re-renders, and it drags).

1. createContext — build the pipe. Its argument is the value used when there is no Provider.

2. <Ctx.Provider value={...}> — pour a value into the pipe. Only its subtree can read it.

3. useContext(Ctx) — read the value. You get whatever the nearest Provider handed down.

4. Wrap it in useTheme(). This step is not optional decoration; it buys two real things: consumers never import the context object, and you get a place to put the guard.

About the default value, the options differ a lot:

The third one is the recommended shape. Under TS strict it has a bonus: the type narrows automatically after the guard, so consumers get ThemeContextValue instead of a union that might be undefined, and nobody has to sprinkle ?. everywhere.

toggleTheme reads the old value to compute the new one, so it has to use the updater form:

Writing setTheme(theme === "light" ? "dark" : "light") also works for a single click, but call it twice inside one event and it gives itself away — both calls read the same old theme, so it only flips once.

One test targets exactly this: a button whose onClick calls toggleTheme() twice, and a correct implementation ends back on light. DrillLab added that test, and a lot of tutorial versions fail it.

toggleTheme also needs to be wrapped in useCallback(..., []). The dependency list is empty because the body only uses the updater form and reads no outside variable, so it never needs rebuilding. This step is what makes the useMemo in the next section work.

Plenty of people write the Provider like this:

The problem is that { theme, toggleTheme } is an object literal — a brand new object on every Provider render. Context decides “did the value change” by reference (Object.is), and a new object counts as changed.

The result: whenever the Provider’s parent re-renders for any unrelated reason, every component calling useTheme() re-renders with it — even though the theme never moved. The bigger the subtree, the more obvious it gets, and React.memo cannot stop it either (memo guards props; context takes a different route).

The fix is useMemo, together with the useCallback from the last section: a new value only appears when theme really changes.

And this is testable — the test drops in a probe component that records every value it receives, then asserts the reference is unchanged after the parent re-renders. Delete the useMemo and run it for real:

The button’s label says where you are going, not where you are. On light it reads Switch to Dark. A lot of people get this backwards — the question states it outright, so circle that sentence while you read.

onClick={toggleTheme} passes the function reference straight through. No need for () => toggleTheme() — that builds a new function on every render for nothing.

The card destructures only theme and leaves toggleTheme alone — take only what you use.

The data-theme={theme} attribute is there for the tests: it is steadier than comparing colour values in style, and changing the palette does not mean changing the tests. Real projects do the same thing (dark mode on this site runs on document.documentElement.setAttribute("data-theme", next) driving CSS variables).

Inside ThemeProvider, children is typed ReactNode — the standard type for “anything that can be rendered”: strings, numbers, elements, arrays, null.

The Provider has to wrap the outermost layer. Only its subtree can call useTheme(); the ThemeProvider component cannot use it inside itself either (at that point the Provider has not rendered yet).

The mindset that matters: do not test the context object, test whether the components wrapped in the Provider behave correctly. So every test assembles its own little tree.

Three techniques worth stealing:

• A probe component — write one right there in the test file that only calls useTheme() and pushes the result into an array. If you want to assert “did the reference change”, this is the only way.
• Silence the console when asserting a throw — React logs a pile of console.error when a render throws; vi.spyOn(console, "error") blocks it temporarily, and mockRestore() puts it back when the test is done.
• Assert on several consumers at once — getAllByTestId grabs the group and you compare the whole array. That test covers the actual point of Context: change it in one place, it changes everywhere.