Components
Forty-one, with a status on each
Grouped by what they are for. The status line on every entry says what will happen to it: stable components change only in a major release, beta components may change in any minor, deprecated components name the release that removes them.
Stable
Twenty-nine components that will not move
A selection of the ones asked about most. The full list, with props, is in the package README.
Button
Four intents and three sizes. The destructive intent asks for a confirmation prop rather than providing a dialog of its own. Loading state replaces the label and keeps the width.
Stable since 1.0
Field
Label, control, description and error in one component, because separating them is how a label ends up unattached. Wraps input, textarea, select and the combobox.
Stable since 1.2
Dialog
Focus trap, scroll lock, and an escape route that cannot be removed. It has no built-in form; put a Form inside it. Nested dialogs are not supported and never will be.
Stable since 1.4
DataTable
Sorting, selection and a sticky header. It does not fetch, paginate or store its own state: you pass rows and it draws them. Virtualised above two hundred rows.
Stable since 2.1
Combobox
Typeahead over a list you supply, with an async loading state. Keyboard behaviour follows the ARIA combobox pattern exactly; we have tested it against four screen readers.
Stable since 2.3
Toast
One region per application, three at a time, newest at the bottom. Errors do not dismiss themselves. There is no toast for a success that the interface already shows.
Stable since 2.0
Pagination
Page numbers, a range summary and a page-size control. Used on every list in every Kalder product, which is the house rule rather than a Bracket rule.
Stable since 1.6
EmptyState
A heading, a sentence and at most one action. It exists so that three teams stop inventing a different empty screen each quarter.
Stable since 2.2
Beta
Nine components that may still change
Each entry names what is undecided. Use them in production if you can accept a rename in a minor release; the changelog will say so and a codemod is provided where the change is mechanical.
FilterBar
Undecided: whether filter state lives in the component or is passed in. Three products want it in the URL and two want it in memory, and until that is settled the props will move.
Beta since 3.0
SplitPane
Undecided: how it behaves below the 48rem breakpoint. It currently stacks; the Vantsen team wants a drawer and has not yet shown that it is better.
Beta since 3.1
CommandMenu
Undecided: whether the command registry is a Bracket concern at all. The rendering is settled, the way commands are registered is not.
Beta since 3.1
DateRange
Undecided: the presets. Everyone agrees on last 7 days and this month and nobody agrees on the rest. Locale handling and keyboard behaviour are settled.
Beta since 3.2
TreeView
Undecided: whether it owns expansion state. Selection is controlled and will stay controlled. Virtualisation is not implemented and a tree of more than about five hundred nodes is slow.
Beta since 3.2
Deprecated
Three components, each with a removal date
They still work and are still shipped. In development they print a warning naming the replacement. Nothing here is removed before 4.0 in March 2027.
Panel
Replaced by Card, which does the same thing with a border token instead of a shadow and works in dark theme without an override. The codemod bracket-codemod panel-to-card handles the common cases; a Panel with a custom header needs a look.
Removed in 4.0, March 2027
InlineAlert
Replaced by Callout. The two were built four months apart by two people who did not know about each other, which is the honest reason. Callout kept the better keyboard behaviour.
Removed in 4.0, March 2027
Stack
Replaced by nothing. It wrapped a flex container in eleven props and was slower to read than the CSS it produced. Use a class with the space tokens.
Removed in 4.0, March 2027
About the list
Questions this page gets
Why is a component I use not listed?
Either it is one of the thirteen smaller stable components left off this page for length, and is in the package README, or it was removed in 3.0 and the changelog says what replaced it.
Can I copy a component out and change it?
Yes, and it is often the right answer for something only your product needs. Copy it, rename it so nobody mistakes it for ours, and keep the tokens. What does not work is patching our component through a class selector; that breaks in a patch release.
How does a component become stable?
Three products use it in production for one full release cycle, no prop changes are outstanding, the accessibility review has passed, and both maintainers agree. The cycle is the part that takes time and is not skipped.
What happens between deprecation and removal?
At least one full major cycle, never less than nine months. The warning appears immediately, the entry here names the release, and the changelog repeats it in every release until the removal.
Is there a Vue or a Svelte package?
No, and none is planned. The tokens are framework-neutral and two teams have built their own components on them, which is the supported path.
Something here is wrong or missing
A component that behaves differently from its entry is a bug in one of the two, and we would rather know which.