Northwind’s 2021 Button had nine props: primary, secondary, danger, small, large, outline, block, icon and onPress. The seven booleans alone allow 128 combinations, and teams found most of them. The production app contained <Button primary danger small large>. It rendered something, and nobody could say what it was meant to be. A component’s API is a contract with every team that uses it, and like any contract, the hard part is what it allows.
The first rule is about the shape of props. If options are mutually exclusive, they belong in one enum prop. If something is on or off, it’s a boolean.
\ntype ButtonProps = React.ComponentProps<'button'> & {\n variant?: 'primary' | 'secondary' | 'danger';\n size?: 'sm' | 'md' | 'lg';\n loading?: boolean;\n startIcon?: React.ReactNode;\n endIcon?: React.ReactNode;\n};With variant as an enum, primary and danger can’t both be true; the type system rejects it before code review. loading stays a boolean because a button is either loading or not, independently of its variant.
The second rule is consistency across components. If Button uses size="sm", so does Input, Select, Tabs and Badge, with the same three values. If one component calls its change handler onChange with the new value, they all do. Northwind keeps a one-page API glossary of shared prop names, and new components reuse those names unless there is a strong reason not to.
This matters more than any single prop decision. An engineer who has used three Northwind components should be able to guess the fourth’s API correctly. Every inconsistency is a small tax paid by everyone, every day.
\nThe third rule: the component must never take away what HTML already gives. A Button is a <button>, so it should accept everything a <button> accepts, aria-* attributes included, and pass it through:
export function Button({\n variant = 'secondary',\n size = 'md',\n loading = false,\n startIcon,\n endIcon,\n type = 'button',\n children,\n ...rest\n}: ButtonProps) {\n return (\n <button\n {...rest}\n type={type}\n className={['nw-button', rest.className].filter(Boolean).join(' ')}\n data-variant={variant}\n data-size={size}\n aria-busy={loading || undefined}\n >\n {startIcon}\n <span className=\"nw-button__label\">{children}</span>\n {endIcon}\n </button>\n );\n}Because ref is a regular prop for function components in React 19, it travels through ...rest with everything else, so focus management and tooltips work without extra wrapping. onClick, disabled, form and aria-describedby work for the same reason.
A slot is a place where the consumer passes content instead of configuration. children is the main slot; startIcon and endIcon are named slots. Compare two ways to add an icon:
<Button icon=\"truck\" iconPosition=\"left\">Assign</Button> // configuration\n<Button startIcon={<TruckIcon />}>Assign</Button> // slotThe configuration version needs the Button to know every icon name and every position, and it grows a prop each time someone wants something new. The slot version accepts any element, so teams can pass a different icon set or a small avatar without a new release. The next lesson takes this idea much further.
\nThe Button writes its props into data-variant and data-size attributes, so the CSS mirrors the API one to one. Each variant changes only component tokens:
.nw-button[data-variant=\"primary\"] {\n --nw-button-bg: var(--nw-color-action-bg);\n --nw-button-text: var(--nw-color-action-text);\n --nw-button-border: transparent;\n}Data attributes keep the styling hooks readable in DevTools, where you see data-variant="primary" instead of a hashed class name, and they can’t be combined into nonsense the way classes like .primary.danger can.
Northwind writes the usage code before the component code. Every new component proposal starts with three snippets: the most common usage, the most complicated usage anyone has asked for, and one usage that should be impossible. The review then asks four questions. Do the prop names match the API glossary? Can any combination of props describe something meaningless? Does the component pass through everything its native element supports? And what will the second and third teams to use it need that the first team didn’t?
\nThat review takes about thirty minutes. Changing an API after twenty teams depend on it takes a major release, a migration guide and months of follow-up, which is what Section 4 is about.
\nIn the exercise, you write the variant and size rules for this Button using only component tokens. Next, you see what happens when a component outgrows props entirely.
\n","toc":[{"id":"sec-1","text":"Enums for choices, booleans for states","level":2},{"id":"sec-2","text":"One vocabulary across the system","level":2},{"id":"sec-3","text":"Don’t block the platform","level":2},{"id":"sec-4","text":"Slots for content","level":2},{"id":"sec-5","text":"Variants in CSS: map props to attributes","level":2},{"id":"sec-6","text":"Review the API before you build it","level":2}],"takeaways":["Use one enum prop such asvariant for mutually exclusive options; separate booleans allow combinations that make no sense.","Keep prop names and values identical across components, so size="sm" means the same thing on a Button, an Input and a Select.","Pass native attributes and ref through to the underlying element, so the component never blocks what HTML already does.","Defaults are design decisions; choose the safe, common option, such as type="button" and a secondary variant."],"further":[{"title":"