Table Card
The shell a data table needs before it stops looking like a prototype: a header block carrying the title, a count and the actions, a body the rows sit flush inside, a footer for the result count and pagination, and a bulk-action bar that rises over the rows it acts on. Like the table primitives underneath it, nothing here holds state — sorting, selection, paging and the loading flag are all yours. No headless table library is installed, and none is needed: the demos below wire every one of those with plain React state.
import {
TableCard, TableCardHeader, TableCardTitle, TableCardDescription,
TableCardCount, TableCardActions, TableCardBody, TableCardFooter,
TableBulkBar, TableBulkBarAction,
} from "@pestoui/core"Header, body and footer
The three blocks. TableCardHeader is a grid, so the title, the description and the action cluster place themselves — no wrapper around the left column, and a header with no description collapses to one row on its own. TableCardBody carries no padding at all: the table draws its own edge inset, which is what lets rows run flush to the card's rounded corners. The footer takes the result count on the left and Pagination on the right, and Pagination centres itself by default, so it needs mx-0 w-auto justify-end here.
Cell content
The four shapes a row repeats. TableCellStack is the name-over-email pair with an optional media slot on the inline-start side; the rest are existing components dropped straight into a TableCell — a StatusBadge, a Progress bar beside its own number, and TableActions holding the trailing icon buttons. Those actions stay visible rather than fading in on row hover: actions that appear under the pointer are undiscoverable, and on a touch screen unreachable.
Compact density
size on the card is the single owner of density: it sets the card's own spacing and the table's cell padding together, so the header, the rows and the footer can never end up on different scales. Only padding and row height move — the text stays put, because a table that shrinks its own type stops matching the page around it. A <Table size> inside still wins if one section really needs to disagree.
Sortable headers
TableSortHeader is controlled and does not sort anything. It renders the arrow for whatever direction you hand it and calls onSort with the direction to move to next; deciding the order and reordering the rows is the caller's job — here, one useState and an Array.sort. Pass null (or leave it off) on every column that is not the sorted one, and align="end" on numeric columns so the arrow sits inside the right-aligned text.
Selection and bulk actions
Same deal: the checkboxes report, they do not select. Keep the chosen ids in state, mark each chosen row with data-state="selected" for the row tint, and drive the select-all box from the same list — checked="indeterminate" when some but not all are picked. TableBulkBar reads open and count off that state and rises over the rows on the panel spring. It is anchored inside TableCardBody rather than portalled, which puts it immediately after the rows in the tab order instead of at the end of the document.
Loading
TableSkeletonRows fills the body while the request is in flight. Give it one column entry per header cell and keep each width close to the real content — a placeholder of the wrong width makes the table jump when the data lands, which is worse than no placeholder at all. The rows are hidden from assistive tech and each one is offset against the stagger token, so the block sweeps down the table instead of flashing as one rectangle. Set aria-busy on the table while they are up.
Empty
TableEmpty renders the row as well as the cell, because the row is the part that goes wrong: an empty state inheriting the row hover fill looks like a clickable record. colSpan has to match the real column count — nothing can validate it, and a wrong number silently breaks the grid. Drop an EmptyState size="sm" inside so the block sits in proportion to the rows it replaced.
Props
Pesto UI · 117 documented components