Data display blocks
Every one of these blocks answers the same question — how should this set of records appear on screen — and they answer it differently enough that picking the wrong one costs a rebuild rather than a restyle.
9 families, 42 blocks
- Tables5 blocksDirectories, trackers, file lists: any record set that is scanned before it is read
- Metrics8 blocksDashboards, reports, KPI rows
- Lists3 blocksSettings, menus, grouped content
- Cards8 blocksListings, profiles, boarding passes
- Kanban2 blocksPipelines, sprint boards, deal tracking
- Calendar3 blocksScheduling, planners, availability
- Timeline5 blocksActivity feeds, audit trails, thread history
- Activity Feed6 blocksDashboards, project history, team updates
- Tree View2 blocksNested settings, parameter trees, schema editors, related-search threads
What these are for
A record set has a shape before it has a layout. Rows that differ only in their values want a table. Rows that each carry a picture want cards. Records that belong to a moment want a timeline or a calendar, and records that belong to a stage want a board. The layout is a reading of the data, so choosing it is a modelling decision that happens to be visual.
The blocks here are the ones where that reading is already made. A table block is not a grid of divs — it is a header that stays put, a row that survives becoming a card on a phone, a cell that knows whether it holds a number or a name. A kanban board is a column set that has already decided what happens when a column is empty. That work is the difference between a component and a screenshot of one.
What they have in common is that they are all containers for something you have. None of them collects anything. If the screen you are building asks the reader for a value rather than showing them one, the blocks you want are in form controls or pickers and search, not here.
Choosing between them
Table or cards?
Ask whether a reader will compare two rows. Comparison needs aligned columns, which is the one thing a table does and a card grid cannot: eyes travel down a column far faster than they travel between two cards. Cards win when each record carries something that does not align — a photograph, a paragraph of description, a status that is the whole point of the record. A table of eight columns where six are empty for most rows is a card grid that has not admitted it yet.
Kanban or table?
A board is a table whose grouping column has become the layout. That is worth doing only when moving a record between groups is a frequent, deliberate action — dragging a card from Review to Done. If the stage is something that happens to the record rather than something a person does to it, a table with a status column is less work to read and much less work to maintain.
Timeline, activity feed, or calendar?
All three are records with times on them. A calendar answers "what is happening on the fourteenth" — it is for a future you are planning against, and its grid is a claim that empty days matter. A timeline answers "what happened to this thing", ordered and usually past. An activity feed answers "what happened lately", across many things, and is read newest-first and abandoned partway down. Using a calendar for history gives you a grid mostly full of nothing.
When is a tree the answer?
When the nesting is the information. A file browser, a schema, a settings hierarchy: the parent-child relationship is what a reader came to understand, and flattening it destroys the thing they are looking at. When nesting is merely how the data happens to be stored, a flat list with a grouping header reads faster and survives a phone better.
Metrics or a chart?
A metric row is for numbers a reader checks rather than explores — today's revenue, open tickets, uptime. It is deliberately one number and one comparison, because that is what gets read at a glance and what stays legible on a phone. The moment the interesting part is the shape over time rather than the value now, the number has stopped being the answer and you want a chart, which is a different kind of component.
Questions
Do these blocks work with my own data?
They are presentation blocks: you own the data-fetching and pass values in. Nothing here assumes a backend, a query library or a schema, because a block that did would be wrong for most of the projects that want it. What they do own is the part that is tedious and easy to get wrong — the sticky header, the empty state, the phone layout, the keyboard behaviour.
Are the tables sortable and paginated?
The table blocks include the header controls and a footer that pagination sits in, and pagination is its own family so it can be used with anything, not only tables. The sorting and paging logic itself is yours, because it belongs next to your query — a component that sorted its own copy of the data would be wrong the moment the set was larger than one page.
How do these behave on a phone?
Each one is built to a narrow layout rather than shrunk into one. A table row becomes a stacked card with its column names as labels; a calendar month drops the weekday words and keeps the marks; a board scrolls its columns with the scrollbar visible rather than hiding that there is more. Every block on this site is checked at desktop, tablet and phone widths before it ships.
The other categories
All documentation
Getting started
Foundations
All components