{"id":"l-ds-3-2","courseId":"design-systems","lang":"en","kind":"lesson","summary":"Recognize prop explosion and replace it with compound components that share state through context, while knowing when a small configured component is still the better choice.","html":"

The first version of Northwind’s ShipmentCard had six props. A year later it had twenty-three: title, subtitle, status, statusTone, showMenu, menuItems, footerText, footerAction, footerActionVariant, hideBorder, compact, imageUrl, imagePosition, and so on. Every team’s slightly different card became one more prop. The component’s code was a thicket of conditionals, and the docs page listed props nobody could keep in their head. This is prop explosion, and every design system meets it.

\n

Configuration versus composition

\n

A configured component receives data and decides the layout itself. A composed component offers pieces, and the consumer arranges them.

\n
\n Left: a single ShipmentCard box fed by a long list of props. Right: a Card box containing Header, Body and Footer pieces that the consumer arranges.\n Configuration\n \n title\n statusTone\n menuItems\n footerText\n hideBorder\n +18 more\n \n \n ShipmentCard\n Composition\n \n Card\n \n Card.Header\n \n Card.Body\n \n Card.Footer\n
One component with many props, versus small pieces arranged by the consumer
\n

Here is the same shipment card, composed:

\n
RouteCard.tsx
<Card>\n  <Card.Header>\n    <Card.Title>Shipment NW-4471</Card.Title>\n    <Badge tone=\"info\">In transit</Badge>\n    <ShipmentMenu shipmentId=\"NW-4471\" />\n  </Card.Header>\n  <Card.Body>Rotterdam to Hamburg · 2 pallets</Card.Body>\n  <Card.Footer>\n    <Button size=\"sm\">Track</Button>\n    <Button size=\"sm\" variant=\"primary\">Assign driver</Button>\n  </Card.Footer>\n</Card>
\n

The card never needed a footerSecondaryAction prop because Card.Footer is a slot that accepts any actions. The menu is the team’s own component, placed where the header allows. Yet the system still owns spacing, borders, typography and responsive behavior of each piece. Teams get flexibility in what goes where; the system keeps control of how each piece looks.

\n

Sharing state between the pieces

\n

Static pieces like Card only need layout. Interactive ones like Tabs need shared state: the selected tab, and which panel to show. The robust way to share it is context:

\n
Tabs.tsx
import { createContext, use, useId, useState } from 'react';\n\nconst TabsContext = createContext<{\n  selected: string;\n  select: (value: string) => void;\n  baseId: string;\n} | null>(null);\n\nfunction useTabs() {\n  const ctx = use(TabsContext);\n  if (!ctx) throw new Error('Tabs.* must be used inside <Tabs>');\n  return ctx;\n}\n\nexport function Tabs({ defaultValue, children }: { defaultValue: string; children: React.ReactNode }) {\n  const [selected, select] = useState(defaultValue);\n  const baseId = useId();\n  return <TabsContext value={{ selected, select, baseId }}>{children}</TabsContext>;\n}\n\nTabs.Trigger = function Trigger({ value, children }: { value: string; children: React.ReactNode }) {\n  const { selected, select, baseId } = useTabs();\n  return (\n    <button\n      type=\"button\"\n      role=\"tab\"\n      id={`${baseId}-tab-${value}`}\n      aria-selected={selected === value}\n      aria-controls={`${baseId}-panel-${value}`}\n      onClick={() => select(value)}\n    >\n      {children}\n    </button>\n  );\n};\n// Tabs.List (role=\"tablist\") and Tabs.Panel (role=\"tabpanel\") follow the same idea.
\n

A trigger reads the shared state wherever it sits in the tree: inside a tooltip, a layout div, or a component the team wrote. In React 19 you render the context directly as a provider (<TabsContext value={…}>) and read it with use. The ARIA roles come from the WAI-ARIA tabs pattern, which you’ll meet properly in the next lesson; keyboard handling is left out here to keep the example short.

\n\n

Composition has costs too

\n

Composition isn’t free. Consumers write more markup, and they can arrange pieces in ways you didn’t intend, such as two footers or a title in the body. Northwind handles this three ways. Each piece is constrained: Card.Footer lays out actions and nothing else looks right in it. Common arrangements ship as documented recipes that teams copy. And a few very common combinations become small configured wrappers built from the composed pieces, such as a ShipmentSummaryCard with four props, so the 80% case stays short while the 20% case stays possible.

\n

Migrating away from a configured component

\n

You rarely get to start fresh. ShipmentCard was used on 60 screens when we redesigned it. We didn’t delete it; we rebuilt it on top of the new pieces, so its 23 props now render Card.Header, Card.Body and Card.Footer internally. Every existing screen kept working and picked up the new styling for free. Then we marked ShipmentCard deprecated, documented the composed equivalent of each common prop combination, and migrated screens team by team. Building the old API from the new pieces is what made the migration boring, which is the highest compliment a migration can get.

\n

When configuration is right

\n

Not every component should be compound. A status Badge has a tone and a label; an Avatar has an image, a name and a size. Their variations are few and closed, so props describe them completely and composition would only add ceremony.

\n

A practical rule from Northwind’s API reviews: when props start describing layout (imagePosition, footerAlign) or content structure (menuItems, footerText), the component wants slots or pieces. When props describe appearance or state (tone, size, disabled), configuration is fine.

\n\n

In the exercise, you judge a Dialog API proposal with these rules. Next, you make sure every one of these pieces works with a keyboard and a screen reader, by default.

\n","toc":[{"id":"sec-1","text":"Configuration versus composition","level":2},{"id":"sec-2","text":"Sharing state between the pieces","level":2},{"id":"sec-3","text":"Composition has costs too","level":2},{"id":"sec-4","text":"Migrating away from a configured component","level":2},{"id":"sec-5","text":"When configuration is right","level":2}],"takeaways":["When every new use case adds a prop, the component is configured from the outside and will keep growing; composition lets consumers arrange pieces instead.","Compound components such as Card.Header and Tabs.Trigger share state through context, not by inspecting children.","The system still owns each piece’s look and behavior, so composition adds flexibility without giving up consistency.","Small, closed components like Badge or Avatar are fine with configuration; reach for composition when props start describing layout or content."],"further":[{"title":"Passing data deeply with context (React)","url":"https://react.dev/learn/passing-data-deeply-with-context"},{"title":"use (React API reference)","url":"https://react.dev/reference/react/use"},{"title":"Tabs pattern (WAI-ARIA Authoring Practices)","url":"https://www.w3.org/WAI/ARIA/apg/patterns/tabs/"}],"quiz":[{"q":"

A team asks for a footerSecondaryActionIcon prop on ShipmentCard. What does this request most likely signal?

","options":[{"text":"The card needs one more prop, and then it will be complete.","why":"Each “last” prop is followed by another; the pattern shows the API has no natural end."},{"text":"The team should build its own card.","why":"A fork loses the system’s styling and fixes; the problem is the card’s API shape, not the team."},{"text":"The card is configured from the outside, so layout and content decisions keep turning into props.","why":"Correct. A footer slot that accepts any actions would have absorbed this request and the next ten."},{"text":"The icon set is missing an icon.","why":"The request is about where content goes, not which icons exist."}],"answer":2},{"q":"

How should Tabs.Trigger find out which tab is selected?

","options":[{"text":"Read it from a context that Tabs provides.","why":"Correct. Context works however deeply the trigger is nested and whatever order the consumer uses."},{"text":"Tabs loops over its children with React.Children.map and injects props.","why":"That breaks as soon as a trigger is wrapped in another element, such as a tooltip or a layout div."},{"text":"Each trigger reads a global variable.","why":"Two tab sets on one page would fight over the same variable."},{"text":"The consumer passes selected to every trigger by hand.","why":"Possible, but it pushes the component’s own state management onto every team."}],"answer":0},{"q":"

Which component is the best candidate to keep as a simple configured component?

","options":[{"text":"A Dialog with a header, body, footer and optional side panel.","why":"Its content and layout vary a lot between uses, which is exactly where composition helps."},{"text":"A data table with custom cells, toolbars and row actions.","why":"Tables vary enormously; configuration-only tables become the biggest prop lists in any system."},{"text":"A status Badge with a tone and a short label.","why":"Correct. Its variations are few and enumerable, so a couple of props describe it completely."}],"answer":2}],"exercise":{"kind":"choice","multiple":false,"options":["props","children-only","compound","per-team"],"correct":["compound"],"title":"Choose the Dialog API","prompt":"

Northwind needs a Dialog. Known uses so far: a delete confirmation (title, sentence, two buttons), a driver-assignment form with a searchable list, a route preview with a map and a side panel, and a marketing newsletter sign-up. Four API proposals arrived. Pick the one you would approve.

\n
TSX
// A\n<Dialog title=\"Delete route?\" body=\"…\" confirmLabel=\"Delete\" confirmVariant=\"danger\"\n        cancelLabel=\"Cancel\" showSidePanel={false} onConfirm={…} />\n\n// B\n<Dialog open={open} onOpenChange={setOpen}>{anything}</Dialog>\n\n// C\n<Dialog open={open} onOpenChange={setOpen}>\n  <Dialog.Header><Dialog.Title>Delete route?</Dialog.Title></Dialog.Header>\n  <Dialog.Body>…</Dialog.Body>\n  <Dialog.Footer>\n    <Button onClick={close}>Cancel</Button>\n    <Button variant=\"danger\" onClick={remove}>Delete</Button>\n  </Dialog.Footer>\n</Dialog>\n\n// D\n// No shared Dialog: each team builds its own on top of the native <dialog> element.
\n","hints":["List how different the four known uses are. Which API absorbs a map with a side panel without new props?","Then ask which option still lets the system own focus handling, spacing and the title’s accessible name."],"explanation":"

Proposal C composes: the system owns the overlay, focus handling, spacing and the title that names the dialog, while teams arrange header, body and footer content freely. A works for the delete confirmation and turns into prop explosion by the second use case. B is flexible but gives up structure, so every team re-solves titles, spacing and footers differently. D throws away the system’s accessibility work entirely. A small configured ConfirmDialog can later be built on top of C for the most common case.

\n","checkLabels":{},"optionText":{"props":{"text":"A: one Dialog configured entirely through props.","why":"It fits the confirmation and fails the map preview; every new use becomes another prop such as showSidePanel."},"children-only":{"text":"B: a Dialog that renders whatever children it receives.","why":"Maximally flexible, but the system no longer owns titles, spacing or footers, so dialogs drift apart again."},"compound":{"text":"C: a compound Dialog with Header, Title, Body and Footer pieces.","why":"Correct. It covers all four uses while the system keeps control of structure, styling and accessibility."},"per-team":{"text":"D: no shared component; teams use the native <dialog> element directly.","why":"The native element is a good foundation for the system’s Dialog, but leaving every team to style and label it recreates the inconsistency the system exists to remove."}}},"words":697,"readMinutes":3}