The Slot Pattern: Making UI Components Composable

Why it exists

A design system cannot predict every single UI need. Overly rigid components become frustrating and are often bypassed by developers, defeating the system's purpose. The slot pattern was created to balance a component's fixed, consistent structure with the need for flexible, custom content composition inside it.

The mental model

Think of a component with slots as a pre-built shelf with designated empty spaces. The shelf itself—the component's frame, padding, and background—is fixed and consistent. But you can place any object you want—your custom content, like text, images, or other components—into the empty spaces, which are the slots. This allows for customization without having to rebuild the entire shelf each time.

How it works

In design tools like Figma, a slot is often a special layer where you can place custom content inside a component instance. In code, this pattern is implemented in several ways. The most common is the children prop in React, where any content placed between a component's opening and closing tags, like in <Card>...here...</Card>, is rendered in a default slot. For more complex components, you can have "named slots," which are passed as specific props, like <PageLayout header={<MyHeader />} footer={<MyFooter />} />.

When to use it

Use slots when a component's "chrome" (its wrapper, layout, and styling) should be consistent, but its content is variable. This is ideal for container-like components. Three key places are: first, general content areas like the body of a Modal or Card; second, components that accept a list of repeating items, like a TabGroup accepting multiple Tab items; and third, complex layouts with multiple distinct areas, like a page shell with slots for a header, sidebar, and main content.

When not to use it

Avoid slots for simple, atomic components like a basic Button or an Icon. These components are meant to be fully encapsulated and configured only through props. Introducing slots here adds unnecessary complexity and defeats their purpose as predictable, self-contained units. If you find yourself wanting to slot content inside a button, you likely need a different, more complex component. The key footgun is that slots blur component boundaries; overuse can lead to a loss of control and consistency.

One canonical example

A Card component is the classic example. A basic Card might have a default slot for its main body content. A more advanced Card could have named slots for a header, media (for an image or video), body (the default), and footer (for actions). This allows a developer to construct many different card variations from a single, consistent Card component, ensuring padding, borders, and shadows are always correct while the content inside is completely custom.