In 04-01 you lifted state to the common ancestor and CicloUrbano's catalogue started filtering for real, but the lesson closed by naming the price of that technique: prop drilling. When a piece of data lives up top and gets used down below, it has to cross every component in between, each of which receives it without using it and forwards it without understanding it. With two levels it's a nuisance; with five, every change to a component's signature forces a manual trek through half the application. useContext is React's answer: a direct channel between a component and any of its descendants, with no stops in between. In this lesson you'll see the concrete problem in CicloUrbano, the three pieces of the mechanism (createContext, the provider, and useContext), how React looks for the nearest provider, the professional provider + access-hook pattern applied to the current user and the visual theme, how to nest and override providers, and — very importantly — when context is the wrong tool.

A scope note before we start: here we study the mechanism of context and apply it to two concrete cases. Context as a strategy for managing state across the entire application — the full pattern, when it scales, when it doesn't, performance, and splitting into several contexts — is the subject of 07-02, in the module devoted to state management. Don't exhaust that debate here: first you need to master the tool.

1. The problem: the current user crossing four levels
2. What context is, and what it isn't
3. The three pieces of the mechanism
4. createContext and the default value
5. The provider in React 19
6. useContext and finding the nearest provider
7. The professional pattern: provider + access hook
8. The complete UserContext for CicloUrbano
9. ThemeContext and switching appearance
10. Nesting and overriding providers
11. When to use context, and when not to
12. The performance warning

CicloUrbano needs to show who's signed in, with a dropdown menu, in the header. The user lives in App, and the menu is four levels down:

Seen as a tree:

The two yellow components are plumbing, not components. And the cost is real:

• Polluted signatures. Layout declares three props it doesn't care about. Anyone reading its code has to follow the trail to understand what they're for.
• Cascading changes. If UserMenu needs the locale tomorrow, you have to touch App, Layout, Header, and UserMenu. Four files for one piece of data.
• Broken reuse. You can't use Layout on a screen without a user without inventing a fake value.
• Test noise. Testing Header forces you to fabricate a fake user even when the test has nothing to do with that.

Context is a mechanism that lets a component make a value available to its entire subtree of descendants, so any of them can read it directly, without receiving it through props.

It's also worth stating what it isn't, since it's frequently misunderstood:

• It isn't a state store. Context transports a value; whoever keeps it still uses useState or useReducer in some component.
• It doesn't replace props. Props remain the normal way to pass data. Context is the exception for what's "ambient".
• It isn't a global channel. It only reaches the provider's descendants. A component outside that branch sees nothing.
• It doesn't break the one-way data flow. Data still flows from ancestor to descendant; the only thing that disappears is the intermediate stops.

The useful mental image: if props are a parcel passed hand to hand down a line of people, context is a PA system. Whoever's provider is speaking; whoever wants to listen, listens; whoever's outside the room hears nothing.

They're always the same three, in the same order:

createContext gets called exactly once per context, at module scope. Never inside a component: it would be recreated on every render and every consumer would lose the connection.

The argument is the default value, and its rule is counterintuitive: it's only used when a component calls useContext and finds no provider above it. If there's a provider, the default value is irrelevant, even if the provider emits undefined.

You have two strategies, and both are legitimate:

Strategy A fits data that has a sensible default (a visual theme, a locale). Strategy B fits data whose absence is always a mounting error (the signed-in user, an API client): you set null and check for it in the access hook, as you'll see in section 7.

In React 19 the context object is used directly as a component. It used to be written <ThemeContext.Provider>, and you'll see that form in practically all existing code and library documentation:

The prop is always called value, whatever language the rest of the project is written in: it's part of React's API, just like children or key.

Two more things about the provider:

• Its reach is its JSX subtree, not its file or module. Anything outside its children doesn't see the value.
• The value can be anything: a string, an object, a function, or an object holding both data and functions. That's the normal case when the subtree also needs to be able to change the value.

useContext receives the context object, not the provider and not the value. And it does exactly this: it climbs up the component tree from wherever it's called, looking for the first provider of that same context.

Important points about how it behaves:

• The search goes upward, never sideways or downward. A sibling of the provider sees nothing.
• The nearest provider wins. If two are nested, the inner one shadows the outer one (section 10).
• If there's none, the default value from createContext gets returned. This is the dangerous case: there's no notice, no error, no console warning. The component just quietly runs on wrong data.

That last point is the whole reason for the pattern in the next section.

Using createContext and useContext on their own scattered across the app has three drawbacks: every component has to import the context, nobody catches a missing provider, and the state logic ends up spread out everywhere. The ecosystem's standard pattern groups everything into one module with three exports: the context (sometimes kept private), a provider component, and an access hook.

The three payoffs, which more than make up for the extra ten lines:

• A missing provider is caught immediately, with a message that says exactly what's missing and where. Without this, forgetting the provider produces a Cannot read properties of null ten components away.
• Consumers never import the context, only the hook. If the context gets split into two for performance tomorrow (07-02), consumers never notice.
• The state lives next to its provider, not scattered around App.

Design details worth explaining:

• The file is .jsx, not .js, because it contains JSX. And its name has no accented characters, following the project's convention.
• UserContext isn't exported. Nobody outside needs it: the provider uses it and the hook reads it. That makes it impossible to skip the validation.
• isOperator is a derived value computed inside the provider. It avoids repeating user.role === 'operario' in every consumer, with the risk of getting it wrong somewhere.
• The functions travel inside the value. Context doesn't just carry data: it also carries the way to change it, which is what lets you stop passing onUserChange down through props.

Now UserMenu reads without searching for anything:

And Layout and Header go back to what they were before prop drilling took over:

The tree, afterward:

And here's main.jsx, with the provider above App and the global error boundary from 04-05 above everything:

The second canonical case. The visual theme gets read by half the application and changed by a single button: the exact definition of "ambient" data.

The initial state uses lazy initialization (05-01) so it doesn't read localStorage on every render, and the effect synchronizes with two external systems (05-02): the <html> element's data-theme attribute and the browser's storage. index.css's CSS variables respond to that attribute:

Notice the split of responsibilities: React manages one piece of data ('light' or 'dark') and the CSS does all the visual work through variables. No component needs useTheme just to render differently; it's only needed by whoever has to decide something based on the theme, such as the button that toggles it:

The aria-pressed comes from 03-06 and the convention already established in TypeSelector: a button that represents a toggleable state must announce it.

The same context can have several providers in different branches, or even nested. The nearest one upward always wins.

Cases where this genuinely comes in handy: a preview that must display with the opposite theme, a section with a different locale, or — very common — testing (Module 9), where you wrap the component under test in a provider with controlled values.

When there are several different contexts, you just nest them. If the staircase gets awkward, a component that groups every provider fixes it:

Context has a cost that doesn't show up in the code: it turns an explicit dependency into an implicit one. Reading <UserMenu /> no longer tells you where its data comes from; you have to open the file. In a component used in only one place, that's worse than a prop.

The fourth row deserves an example, because plenty of people reach for context when composition would have been enough. This Layout receives user only to hand it to the header:

With a named slot (04-02), the data stops crossing anything at all:

Layout no longer knows anything about the user: it receives an already-built element. Before setting up a context, check whether composition solves the case; it's simpler and keeps dependencies visible.

The rule that sums up this section: context is for ambient data that many read and few change. When the data is specific to one concrete interaction, props remain the answer.

One sentence, and we'll expand on it in its own place later: when a context's value changes, every component that consumes it re-renders, even if it only uses part of the value and that part didn't change. With a theme that gets toggled twice a day, this is irrelevant; with a value that changes on every keystroke, it matters.

The techniques for managing it — splitting a context into several by how often each part changes, separating data from the functions that modify it, and memoizing the provider's value — belong to 07-02 and to Module 8. For now, just hold on to the idea that the cost exists, and get in the habit of not lumping things that change at very different rates into the same context.

• Calling createContext inside a component. A new context gets created on every render, and consumers stop finding the provider. It always belongs at module scope.
• Forgetting the provider. Without the pattern from section 7, there's no error: the component gets the default value and silently misbehaves. With the access hook that throws, the failure shows up on the very first render with a clear message.
• Believing the default value is used when the provider emits undefined. It isn't: it's only used if there's no provider anywhere in the chain.
• Providing from the wrong component. The provider has to sit above every consumer. Put it inside Header, and the catalogue won't see it.
• Cramming the whole application's state into a single context. Any change re-renders every consumer. One context per concern.
• Using context to pass data to a direct child. That's over-engineering a prop. Context starts paying off at three levels or more, and only when there are several consumers.
• Exporting both the context and the hook without a reason. Exporting only the provider and the hook stops anyone from bypassing the validation.
• Tip: name the hook use + the noun (useUser, useTheme). Beyond the convention, it's required for the linter's hook rules to recognize it as a hook (04-04).
• Tip: in tests, wrap the component in its provider with fixed values. If that feels hard, it's usually a sign the context has too many responsibilities.
• Tip: put the derived values several consumers would need (isOperator) in the context's value, not just the raw data. It avoids repeating the same condition everywhere.

Exercise 1. This CicloUrbano code fails at runtime with "Cannot destructure property 'user' of null". Find the two causes and fix them.

Exercise 2. Create NoticesContext with the provider + access hook pattern. It must let any component in the tree show a global notice without receiving props: the provider keeps a list of notices { id, tone, text } (the tones are Notice's: info, success, warning, error), exposes showNotice(tone, text) and dismissNotice(id), and renders the notice stack above children. Also show how BookingForm would use it when creating a booking.

Exercise 3. BikeCard should show a "Send to workshop" button only if the current user is an operator (usr-02, Marc Solé). Today it receives user as a prop from App, crossing through BikeList. Rewrite it using useUser, and explain which props disappear from each component in the chain.

Solution 1.

The two causes:

1. App calls useUser(), but App itself is the one rendering <UserProvider>. A component can't consume a context that it provides itself: useContext's search goes upward, and the provider sits below the line where the hook is called. useContext returns null (the default value), and the destructuring blows up.
2. user.name is read without checking that a user exists. The provider allows signOut(), which sets user to null; that <p> would fail the moment someone signed out.

The fix moves the provider above App (in main.jsx) and extracts the greeting into a descendant component:

Solution 2.

Used from BookingForm, without a single new prop added to the chain:

This is context's ideal use case: notices are ambient (any component can raise one), they render in a single place, and nobody needs to know how they get there. Without context, showNotice would have to be passed as a prop from App down to every form and panel in the application. Also notice the role="status" with aria-live="polite" from 03-06: notices appear without moving focus, so they need to be announced.

Solution 3.

Props that disappear from the chain:

Notice what hasn't changed: onSendToWorkshop is still a normal prop. The user is ambient data, but "what to do when this specific button on this specific card gets pressed" is the parent's call, and that's props territory. Mixing the two up — stuffing everything into context because it's convenient — is the mistake that turns an application into a tangle.

The prop drilling that 04-01 left hanging now has a name and a fix. Context is a direct channel between an ancestor and all of its descendants, always built from the same three pieces: createContext(defaultValue) in a separate module, a provider that in React 19 is written <Context value={…}> — with <Context.Provider> still working in code you inherit — and useContext(Context), which climbs the tree to the nearest provider and, if it finds none, silently returns the default value. That's why the professional pattern wraps all three pieces in a module with provider + access hook that throws a clear error when the provider is missing: that's exactly how you built UserContext and ThemeContext, with Layout and Header getting their clean signatures back. You know how to nest providers to override the value in one branch, and — most importantly — you know when not to use it: for direct children, props; for siblings, lifting state up; for plumbing, composition with children. Context is for what's ambient: user, theme, locale, permissions, notices.

One front is still open. UserProvider managed a single simple value, but CicloUrbano's booking state isn't simple: there's a list of bookings, a draft in progress, a submission phase, and a possible error, and all those pieces change together and by rules. With useState you'd end up with five loose variables and handlers that touch three at once — exactly the situation 05-01 flagged as the limit of that tool. React offers an alternative that gathers every transition into a single pure function, easy to read, to test, and to reason about. The next lesson is The useReducer Hook.