BridgeHandbookDraft
For agents
Menu
Draft

All components

Every component with its level, category and status.

Every component

37 components are in @brdgapp/ui. Each has a page with live examples, guidance and its API. Search or filter to find the one for a job.

37 of 37 components

How components are organized

The handbook follows Atomic Design (Brad Frost), as Oration's Canon does: small parts combine into bigger ones, and the levels say how big a part is. Every component page shows its lineage: what it's built from and where it's used.

LevelWhat it isIn the handbook
AtomsThe smallest parts. Split one up and it stops being useful.Button, Tag, Switch, SearchInput
MoleculesA few atoms working together as one unit, doing one job.ButtonGroup, ActionMenu, StatBox, Tabs
OrganismsA complete piece of a screen, made of molecules and atoms.DataTable, Dialog, ConfirmDialog, Drawer
TemplatesA page shape: where the organisms go, with placeholder content.The Templates section (Card dashboard, Record page…)
PagesA template with real content: what people actually see.Real app screens, on each app's page (Bridge OS)
  • It isn't a sequence. Work on the part and the whole together: a page with real content (a very long name, an empty list) often shows that an atom needs to change.
  • Utilities (DataState) sit outside the levels: shared behavior with little look of its own.
  • Deciding a level: if it does one thing and can't be split, it's an atom. If it combines a few atoms for one job, a molecule. If it's a whole section of a screen, an organism.

Statuses

Every component has a status that says how safe it is to build on. A component moves up when it meets the next status's conditions.

Experimental

In the package with a handbook page, but no app uses it from the package yet. Its API may still change.

  • It's in @brdgapp/ui, on Bridge tokens, with data-slot names and named exports.
  • Its handbook page has a summary, live examples and an API table.

Beta

Used from the package on at least one real screen. Safe to adopt; changes are announced in the changelog.

  • At least one screen in one Bridge app imports it from @brdgapp/ui.
  • Every guidance section is written (the build checks this).
  • Its known gaps are listed.

Stable

Shared across Bridge. Its API only grows: nothing is renamed or removed without going through Deprecated first.

  • Used from the package in two or more places, or by a second app (the sharing rule, decided 2026-11-02).
  • Checked with a keyboard and a screen reader, in light and dark, at 390px and 1440px.
  • Every guidance section is written, and no known gap affects accessibility.

Deprecated

Being replaced. Don't use it in new work.

  • Its page names the replacement and the version it will be removed in.

Today every component is Experimental: no Bridge app imports them from the package yet. Bridge OS’s move onto the package is ready in a merge request; once it’s merged, the components it uses become Beta.

Rules

One of each

Bridge has one button, one label, one menu, one tooltip, one confirm dialog and one table. Before building a control, look for it here. Never hand-make a second version (a <button> with pill classes, a <span> chip, a new kebab), even if it looks the same today: copies drift.

Fix the system first

If the system can't express something a screen genuinely needs, extend the component (a new size, a new option) and document it in the same change, then use it. Never work around a gap at the call site. A 1–2px change from the old design is the expected cost of joining the system, not a reason to stay hand-made.

Share at two

A component moves into the package once two places in one app need it, or as soon as a second app does. A near-copy becomes an option on the existing component, not a second component.

Not decided yet

Until these are settled, follow Bridge OS as it is today.

  • The status criteria below are a proposal (2026-11-02), waiting for Aman's approval.

Sources

  • The registry (registry/pages.ts), read when the page builds.
  • Status criteria: registry/statuses.ts, adapted from Oration's lifecycle method and Bridge's sharing rule.
  • Brad Frost, Atomic Design (atomicdesign.bradfrost.com), chapters 2 and 3: the five levels, part and whole, pattern lineage.