14.
Context & App-Level Preferences
Written by Eli Ganim
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.
Unlock now
In the previous chapter, you tamed the network. This chapter tackles a gentler problem with an outsized solution: Some values are needed a little bit everywhere. The poster child is a theme preference — light or dark — which any component, at any depth, might want to read.
Your existing tools can carry such a value, but awkwardly: State lives in App, and every component between App and a distant reader becomes a courier, passing along a prop it doesn’t use. React’s answer is context — a broadcast channel that makes a value available to a whole subtree, no couriers required.
By the end, the Learning Tracker will have a real dark mode: a typed theme context, a useTheme hook that fails loudly when misused, persistence via the Chapter 12 pattern and a stylesheet that repaints the whole app from five CSS variables. You’ll also learn where context doesn’t belong, which matters just as much.
The Courier Problem
Feel the pain before buying the cure. Suppose theme state lived in App the usual way — read, don’t type this:
const [theme, setTheme] = useState<'light' | 'dark'>('light')
PageHeader hosts the toggle button, so it needs both the value and a setter — two more props. Tolerable. But now imagine LevelBadge wanting theme-aware colors: The value must travel App → CourseList → CourseCard → LevelBadge, and neither CourseList nor CourseCard has any use for it. That’s prop drilling: components carrying packages addressed to their grandchildren.
Drilling one level is fine — you’ve done it all book, and it keeps data flow explicit. Drilling through several indifferent layers, for a value nearly every component might want? That’s the specific ache context exists to cure:
A provider component wraps a subtree and offers a value; any component inside the boundary can read it directly. The value teleports past the couriers.
Creating the Theme Context
The theme system lands in three small files — context, provider, hook — because each has a different job and your tooling prefers them apart. Start with the channel itself. Create src/ThemeContext.ts:
import { createContext } from 'react'
export type Theme = 'light' | 'dark'
export type ThemeContextValue = {
theme: Theme
toggleTheme: () => void
}
export const ThemeContext =
createContext<ThemeContextValue | null>(null)
Building the Provider
The channel needs a broadcaster: a component that owns the state and offers it. Create src/ThemeProvider.tsx:
import { useEffect, useState } from 'react'
import type { ReactNode } from 'react'
import { ThemeContext } from './ThemeContext.ts'
import type { Theme } from './ThemeContext.ts'
function loadTheme(): Theme {
const stored = localStorage.getItem('learning-tracker-theme')
return stored === 'dark' ? 'dark' : 'light'
}
type ThemeProviderProps = {
children: ReactNode
}
export function ThemeProvider({
children,
}: ThemeProviderProps) {
const [theme, setTheme] = useState(loadTheme)
useEffect(() => {
localStorage.setItem('learning-tracker-theme', theme)
document.documentElement.dataset.theme = theme
}, [theme])
function toggleTheme() {
setTheme((current) =>
current === 'light' ? 'dark' : 'light',
)
}
return (
<ThemeContext value={{ theme, toggleTheme }}>
{children}
</ThemeContext>
)
}
import { ThemeProvider } from './ThemeProvider.tsx'
<StrictMode>
<ThemeProvider>
<App />
</ThemeProvider>
</StrictMode>,
Reading Context Safely
Consumers could call React’s useContext directly, but every one of them would face the same null question. Centralize the answer once. Create src/useTheme.ts:
import { useContext } from 'react'
import { ThemeContext } from './ThemeContext.ts'
import type { ThemeContextValue } from './ThemeContext.ts'
export function useTheme(): ThemeContextValue {
const value = useContext(ThemeContext)
if (value === null) {
throw new Error(
'useTheme must be used inside ThemeProvider',
)
}
return value
}
import Button from './Button.tsx'
import { useTheme } from '../useTheme.ts'
const { theme, toggleTheme } = useTheme()
<Button
label="Dark mode"
variant="ghost"
onClick={toggleTheme}
pressed={theme === 'dark'}
/>
Teaching the Stylesheet About Themes
Hard-coded colors can’t follow a preference; CSS custom properties can. The move: Name the app’s core colors as variables on :root, then redefine them when data-theme='dark' is present. Replace the entire contents of src/index.css with:
:root {
color-scheme: light;
--page-bg: #f4f6f8;
--text: #22272e;
--text-muted: #57606a;
--surface: #ffffff;
--border: #d8dee6;
}
:root[data-theme='dark'] {
color-scheme: dark;
--page-bg: #14181d;
--text: #e8ebef;
--text-muted: #9aa4b1;
--surface: #1d232b;
--border: #39424e;
}
* {
box-sizing: border-box;
}
body {
margin: 0;
font-family: system-ui, 'Segoe UI', Roboto, sans-serif;
background: var(--page-bg);
color: var(--text);
line-height: 1.5;
}
color: #ffffff;
:root[data-theme='dark'] .featured-banner {
color: #6a4a00;
}
:root[data-theme='dark'] .category {
color: var(--text-muted);
}
:root[data-theme='dark'] .button.ghost {
color: #9db9e8;
border-color: #9db9e8;
}
:root[data-theme='dark'] .field-error {
color: #f1959b;
}
:root[data-theme='dark'] .success-note {
color: #7fd39a;
}
:root[data-theme='dark'] .in-plan-note {
color: #9db9e8;
}
What Context Is — and Isn’t — For
Context is so pleasant to use that the temptation is to put everything in it. Resist, because each kind of app data already has a better home:
Challenge: Add a Density Preference
Some users want airier cards; some want more on screen. Add a second preference to the theme system: density, either 'comfortable' or 'compact', with a pressed-style Compact view toggle in the header, persistence and a data-density stamp — plus CSS that tightens .card padding and the catalog gap when compact.
Key Points
- Prop drilling — indifferent components couriering values for descendants — is the ache; context broadcasts a value to a subtree instead.
-
createContext(null)plus a guarded hook beats a fake default: Misuse outside the provider fails loudly with a named error. - A provider component owns the state and renders
<SomeContext value={...}>around its children — React 19’s direct syntax for the older.Providerwrapper. - Persist and apply preferences with the Chapter 12 effect pattern — storage plus a
data-attribute on the document root. - Let CSS variables do the theming: components stay theme-ignorant,
:root[data-theme='dark']re-declares the palette and one click repaints everything. - Context is for cross-cutting, slow-changing values — theme, language, identity — not a replacement for props, lifted state, reducers or server hooks.
- Every consumer re-renders on value change; broadcast accordingly.
Where to Go From Here?
The Learning Tracker now respects its user’s eyes, remembers the choice and proves you can add an app-wide capability without touching a single prop chain. Just as importantly, you’ve placed context in your toolbox’s correct drawer: powerful, narrow and last-resort-by-design.