Compound Pattern vs Composite Pattern

These terms are often confused, but they describe different compositional approaches in Design Systems.

Compound pattern: A collection of related subcomponents that share internal state and coordinate through context or props. A Dialog with Trigger, Header, Body, and Footer is a compound. Each piece is a separate component, but they're designed to work together and depend on the parent's state. You can't use Dialog.Header without Dialog wrapping it.

<Dialog> <Dialog.Trigger>Open</Dialog.Trigger> <Dialog.Header>Title</Dialog.Header> <Dialog.Body>Content</Dialog.Body> <Dialog.Footer>Actions</Dialog.Footer> </Dialog>

Composite pattern: A hierarchy of independent components that can be nested but don't require context or shared state. A Menu with Items, an Accordion with Panels, a Form with Fields — each subcomponent is self-contained and the parent simply renders them. You could use a MenuItem outside a Menu and it would still work (though it might not make semantic sense).

The compound pattern is more opinionated and tightly bound. It ensures consistency (all Dialog.Header elements get the same styling) and enables complex interactions (Dialog.Body knows how tall it can be because Dialog manages the viewport). It's also harder to customize — extending Dialog.Header is more work because it's coupled to Dialog's context.

The composite pattern is looser. Components are more reusable and testable in isolation. But the parent has to do more orchestration work, and there's more room for inconsistency.

Most modern Design Systems use a mix. Low-level components (Button, Input) are composite (standalone). High-level components (Dialog, Tabs, Accordion) are compound (interdependent). The rule of thumb: if subcomponents need shared state to function correctly, use compound. If they're just grouping, use composite.

Related: Composition · Compound components · Component API · Slots