Component library
The technical contract.
If the design system decides what the interface is made of, the core component library is the interface that user-interface code is actually written against. A component's props, its states and its accessible behaviour are its schema. It is established before any feature exists and consumed by all of them — so a story composes from it rather than adding to it, and most screen-level decisions stop being decisions. That is the point: not reuse for its own sake, but a much smaller set of things anyone still has to get right by hand.
What a component promises
Four clauses. A component that answers all four can be depended on without reading its source, which is the only definition of a component library that means anything.
Props
The names, the types, the defaults and — as important — what is deliberately not exposed. An escape hatch added quietly becomes the contract everyone depends on.
States
Rest, hover, focus-visible, active, disabled, loading, error, empty, read-only. One story each, so a missing state is a visible gap rather than an implementation detail.
Accessible behaviour
The role it exposes, the name it takes, the keyboard model it implements, and what it announces when it changes. These are guarantees, not options.
Tokens consumed
Which design-system roles it reads. That is the seam where the visual contract enters the technical one, and it is the only place a colour may be decided.
The catalogue
38 core components in six groups, 26 of them under a settled contract. The status is about the contract, not the appearance:beta means the props may still change under you. Anything a feature team composes on top of these is theirs and is not listed here.
Actions
How does the user ask for something to happen?
The controls that commit a user to something. Their contract is mostly about states — a button that cannot express "in progress" pushes every caller into inventing one.
- ButtonStableThe primary, secondary and destructive commit action.
- IconButtonStableA compact action that still needs an accessible name.
- LinkStableNavigation, styled apart from actions on purpose.
- MenuButtonBetaOne action with alternatives behind it.
- CopyButtonBetaCopy to clipboard with the confirmation users need.
Forms and input
How does the user tell the system something?
The largest group, and the one where an inconsistent contract costs the most: label association, error placement, required marking and validation timing are accessibility guarantees, not styling choices.
- TextFieldStableSingle-line text, with label, hint and error slots.
- TextAreaStableMulti-line text with a character budget.
- SelectStableOne of a known, short list.
- ComboboxBetaOne of a long or remote list, with typeahead.
- Checkbox / RadioStableMultiple choice and single choice, including the indeterminate case.
- SwitchStableA setting that applies immediately — never a form field.
- DateFieldBetaA date, typed or picked, with locale and range rules.
- FileUploadPlannedAttachment with progress, size limits and failure.
- FormBetaSubmission, validation timing and the error summary.
Feedback and status
How does the system tell the user what just happened?
The group that decides whether a journey recovers from a failure or ends at it. Every one of these has an announcement contract — what a screen reader says, and how urgently.
- ToastStableA transient confirmation that must not steal focus.
- BannerStableA persistent condition affecting the whole page.
- DialogStableA modal interruption, with focus trapping and a way out.
- ConfirmDialogStableThe last chance before something irreversible.
- EmptyStateBetaNothing here yet — and what to do about it.
- ErrorStateBetaIt failed: what happened, why, what next.
- SkeletonStableLoading, without a layout shift when the data lands.
Data display
How is a lot of information made readable?
Where density, sorting, selection and responsiveness meet. The table is the component most often forked in a hurry, so its contract is the one worth agreeing hardest.
- TableStableRows and columns with sort, selection and a real caption.
- DataGridPlannedThe same, virtualised, for sets too big to render.
- CardStableOne entity, summarised, in a grid of its peers.
- DescriptionListStableKey and value pairs that stay associated.
- TagStableA status or a category, never colour alone.
- ChartPlannedA visualisation with a text alternative beside it.
Layout
What holds the rest of it together?
The primitives that make spacing a decision taken once. They carry no visual identity of their own, which is exactly why they keep every screen on the same grid.
- StackStableVertical and horizontal rhythm from the spacing scale.
- GridStableThe responsive column grid, per breakpoint.
- ContainerStableMeasure and gutters, so text stays readable.
- SurfaceStableBackground, border and elevation as one decision.
- DividerStableA separation that is decorative to assistive technology.
The running artefact
A catalogue nobody can run is a document. Storybook is where the contract is exercised — every state as a story, interaction tests and accessibility scans against those stories, and the same stories snapshotted so an unintended visual change has somewhere to show up.