Turn tokens into reusable UI — learn what makes a component reusable, how atomic design organizes a library from atoms to pages, and why documentation is what makes a system actually get used.
Why: a reusable component is configured through props, styled from tokens (not hardcoded values), and accessible by default — so every team gets the same correct, on-brand piece without rebuilding it. The opposite is a one-off that only fits the screen it was born on. Note: if you have to copy-paste and tweak it for the next screen, it is not yet reusable.
// Configurable via props, styled from tokens, accessible by default
type ButtonProps = {
variant?: 'primary' | 'secondary'
children: React.ReactNode
} & React.ButtonHTMLAttributes<HTMLButtonElement>
function Button({ variant = 'primary', ...props }: ButtonProps) {
// A real <button> — keyboard and screen-reader support for free
return <button className={`btn btn-${variant}`} {...props} />
}Why: atomic design is a popular way to organize a component library by borrowing from chemistry. You build up from the smallest pieces, so bigger things are always composed of smaller, already-tested ones. Note: it is a mental model for structure, not a strict rule — the value is the habit of composing small, reusable parts.
Atoms the smallest building blocks — Button, Input, Label, Icon
↓
Molecules a few atoms combined — a SearchField (Label + Input + Button)
↓
Organisms molecules + atoms into a section — a SiteHeader, a ProductCard
↓
Templates arrange organisms into a page layout (no real content yet)
↓
Pages a template filled with real content — the final screenWhy: as components grow, resist piling on dozens of boolean props. Prefer composing small pieces together — it stays flexible and readable far longer than one component trying to do everything through flags. Note: a Card you fill with children beats a Card with a dozen show/hide props.
// ❌ A "god component" configured by an explosion of props
<Card title="Hi" hasFooter footerText="OK" showImage imageUrl="…" />
// ✅ Composition: small parts assembled by the consumer
<Card>
<Card.Image src="…" />
<Card.Title>Hi</Card.Title>
<Card.Footer>OK</Card.Footer>
</Card>Why: an undocumented design system goes unused — people can't adopt what they can't find or understand. Each component needs its variants, states, props, and usage guidance ("do this, not that") written down, ideally in a living tool that renders the real component. Note: Storybook is the most common tool for this — an interactive catalog of every component and state.
# A documented component answers, in one place:
# - What variants exist? (primary, secondary, danger)
# - What states? (default, hover, focus, disabled, loading)
# - What props, with types? (and which are required)
# - When should I use it — and when should I NOT?
#
# Storybook renders each component in every state as a living, browsable
# catalog, so designers and developers share one source of truth.