Context lets children adapt to the container they sit in

What it is

Component context propagation lets an ancestor send “what container you are in” down the tree, so descendants change their size, spacing, dividers, and keyboard scope without every layer re-exposing those values as props. Buttons in a toolbar go compact, selects in a table row go short, labels in a field group go top-aligned — the child adapts to the container it sits in, not to size parameters handwritten at each call site.

It answers “where am I”, not “whose legal child am I”. The child already sits legally under the parent; context tells it the parent’s present environment: density, orientation, surface role, whether it is inside a collapsed overflow.

Why it happens

If a container’s environment is forwarded as props, every intermediate layer must know those props even when it does not use them. Drop one layer and deep controls fall back to defaults, no longer matching their neighbours. The property table also collides with local overrides in the middle: is this the toolbar’s compact, or this one button’s compact? Readers cannot tell.

Context makes environment an implicit argument of the tree: the provider writes once at the container root, consumers read at the leaves. Intermediate layers can be transparent and need not declare keys they do not care about. Overrides happen at a nearer provider; the distance rule is clear. Children can therefore switch metrics across containers while remaining the same role outwardly — a button is still a button, it has merely read “I am in a toolbar”.

Where it stops holding

Trees that cross documents, iframes, or portals cut context; children read defaults and must be re-provided at the boundary. A context-reading component rendered on a storybook island with no container will paint a default bulk that never appears in the product, so the preview lies. Stuffing brand colour and theme axes into the same component context tangles “which container am I in” with “which skin am I in”; the latter has its own retargeting layer. Local exceptions the call site must make explicit (this one button is larger) should go through props, not a parallel context, or two sources will step on each other.

Applying it

• List what the container ships: density, orientation, surface, collapsed or not. Write the default for each value and who may override it.
• Provide context at the container root and read it at the leaves. Intermediate layout components pass through by default; they do not split the environment into their own props to hand down.
• Give isolated renders a test provider so default bulk from storybook does not leak into product screenshots.
• How to check: place the same button in a toolbar, a table cell, and a form row with no size props. Height, padding, and icon size should follow the container in all three. Then insert a layout component in the middle that does not know the environment: the three presentations must not change — if they do, a hop was dropped. Finally enlarge one button via a prop: only that one changes; neighbours still follow the container.

Related

• Same group: R1.11.1 Slots return the decision about content to the consumer · R1.11.2 Assembly is less ambiguous than passing props · R1.11.3 Legal parent-child pairings need explicit constraints
• Adjacent: R1.02 Component library and variants · R1.01 Named values
• Search terms: component context propagation · container context · context provider