The steady screens
Every screen the suite is built from, live and yours to configure. Open one, move its knobs, and see what it becomes.
Records table
Reach for this when many records need columns, sorting and grouping in one scannable grid —
columns: carries every bit of semantics, groupBy: and density: do the rest. The shape most screens take: a records table under the app shell, with grouping, sorting and per-row actions live. Change grouping to see the table regroup without touching the data. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.Records list
Reach for this as the compact-class counterpart of the table — the same collection below the table breakpoint, one primary line per record under the same narrowing chrome. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (
fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.Records cards
Reach for this to browse records as cards — five postures from dense scan rows to media browse tiles, with
onOpen: as the card's single primary action. cardFor binds each row to posture-free slots and the grid picks the posture itself, so the record-to-media swap is the grid's decision rather than the screen's. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.Records gallery
Reach for this when records are primarily images and the grid of tiles IS the collection. Rendered here with no image value, which is the real fallback state rather than a broken one. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (
fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.Records map
Reach for this for any spatial view — pins on a geographic basemap or on a fixed background image, one widget for both. The selected record docks as a detail pane rather than a bespoke summary panel. A verb on this screen has three homes and none of them is the bar: the primary one is the Fab (
fab), view verbs like Export are the view-options surface's header affordance, and a record's own actions belong to the pushed record surface — see Detail's hosting knob.Dashboard
Reach for this when several measures share one screen and one narrowing — a snap grid of tiles, each never blank. A dashboard SCREEN is the records floorplan with its dashboard body (
RecordsScreen + the dashboard slot); these are the parts it assembles. A tile's tap filters or opens, never both: a filtering tap scopes its value and every tile that reads that dimension reacts, because the bus broadcasts the predicate and excludes each tile from its own dimension, while an OPEN table's row or a map pin opens its record and writes nothing. A tile body insets flow content by 12 and leaves a table, a map or a platter flush — inset: overrides the inference from fillsBody: — and a grouped body is LabeledSection over a category grid, per group.Detail
Reach for this for one record in full —
mediaHeader: and fieldLayout: shape it, and it stays generic over the record type. It OPENS at large: the two-up split (960 and up) and the fields grid's third track (1200 and up) both show by default — paneAtEnd swaps which side the fixed pane takes. Start with sectionNav either way; it is a view-type swap rather than a setting, and tabs, jump and the plain stack are three different screens.Form
Reach for this for any new or edit record form —
fields: declares the shape, onSave: commits, autoAdvance: moves focus. Never hand-assemble a column of fields. Shown in the EDIT posture — a record loaded by id, every field seeded from it, and the delete affordance a new-record form does not have. It brings its own chrome, so this is the whole screen.Thread
Reach for this for a feed or an open conversation — posts, replies, system events and the composer, as one grammar. The reply affordance is the surface's one loud action.
Settings
Reach for this for a grouped-settings screen — a micro-label heading over the kit's framed list, repeated per group. No spec of its own; it is the design system's settings reference screen made portable. Switches for instant-effect toggles, never a hand-rolled rows list.
Add people
Reach for this wherever a user brings people in, scoped to where they stand: invite by pasted email addresses, or make a join link with its expiry, use cap and approval, each with the access it grants. A pattern over the kit's fields, the same on both kits. The host passes the access it may hand out and does the inviting, so it names no access model.
Home
Reach for this for a person's front door: the apps (or any destinations) they can open, as a grid of category cards under a greeting, with no rail, no search and no facets. The floorplan owns the band (the brand, the organization item, the account button and sync), the greeting, the grid and its faces: the first sync on its way, and the empty face whose copy is yours. A door list that needs search, sort or grouping is a RecordsScreen, not this. Step through
face to see each, and set organizations to two to see the organization item.Import
Reach for this when a batch of records comes in — a file upload or a pull — and someone has to review what is staged before anything is committed. The floorplan owns the frame: the phase line, the summary band and its filter doors, the checks that gate Confirm, the commit footer and the discard dialog. The review body is yours, and a RecordsScreen there nests as embedded. Step through
phase to see every face, and change confirmGate to see how Confirm waits for the checks.Reader
Reach for this when someone reads one multi-page document — a handbook, a drawing set, a scanned form — one page at a time. The floorplan owns the frame: the page strip, the stage and its zoom, the page and load faces, the keys, and the details column beside the page. You resolve each page to an image or a page of a PDF and render the details. Step through
state to see each face, and turn initialDetailsOpen off to start with the stage alone. Give it a markup binding per page and it draws and edits the page's real PDF annotations: the markup layer over the page, its toolbar, the comments panel in the details column and the conflict notice on the stage's modeline. A host composing those pieces beside a page of its own wraps them in one markup scope.Everything else
Components
One board per family: every variant of one kind of thing on one canvas, hand-authored. The per-class pages this replaced mostly rendered from generated builders that guessed their required parameters, which is why the small components were not worth looking at.
Wiring
The plumbing a screen sits in — capture, media, export, auth, reading scale, entrance. Nothing here is a thing you look at; it is the part you need when you are wiring something up.
Nothing fits? Building with it carries the
sourcing gate — four legitimate answers, only one of which is "use the kit
widget".