Data Table

Demo & usage

More examples

<sv-data-table
  [rows]="rows"
  rowKey="id"
  [searchable]="true"
  [showToolbar]="true"
  [selectable]="true"
  [bulkActions]="bulkActions"
  [pageSize]="20"
  (rowClick)="open($event)" />

<sv-data-table
  [rows]="pageRows"
  [serverSide]="true"
  [totalCount]="total"
  (serverPageChange)="load($event)" />

<!-- Drops the table's own white fill so it blends into a glass card
     or coloured panel; keeps hover/selection tints. Pair with
     variant="borderless" so only the parent card's border shows. -->
<div class="rounded-2xl border bg-white/70 backdrop-blur-xl p-1">
  <sv-data-table-pro [columns]="columns" [rows]="rows" rowKey="id"
    [transparent]="true" variant="borderless" [paginated]="false" />
</div>

<sv-data-table [columns]="columns" [rows]="rows" rowKey="id">
  <!-- Render any rich content per column, keyed by the column's `key`. -->
  <ng-template svDtCell="name" let-row let-value="value">
    <sv-avatar [name]="row.name" size="xs" /> {{ value }}
  </ng-template>
  <ng-template svDtCell="status" let-row>
    <sv-badge [label]="row.status" [variant]="statusVariant(row.status)" />
  </ng-template>
</sv-data-table>

<!-- Transposes rows→columns: first column = product name, the rest
     become feature rows; boolean values render as check / cross. -->
<sv-data-table-pro [columns]="columns" [rows]="products" rowKey="id"
  layout="comparison" highlightRowId="pro" />

When to use

• Displaying structured rows that users sort, page, search, or select.
• You need selection, bulk actions, density toggles or column visibility.
• For unstructured/feed-style content, use List View instead.
• Up to ~200 rows: render them unpaged. Every row is in the DOM, so nothing needs configuring.
• 200 rows to ~10k, held in the browser: `paginated` (or `virtualized` for one continuous scroll). The client pipeline — search, filter, sort and windowing over the whole set — measures 0.5ms at 1k rows and 4.4ms at 10k, so a keystroke still lands inside one frame.
• 10k to ~25k: `virtualized` keeps rendering flat (the DOM holds `viewportHeight / virtualRowHeight` rows plus a small overscan no matter how large the set is — a 240-row table renders 13 `tr`s), but the pipeline is linear in row count and search is what runs it. Turn `searchable` off, or move to `serverSide`.
• Beyond ~25k rows: `serverSide`. The pipeline costs 21ms at 50k rows, so each keystroke drops a frame — and that is before the memory of holding the set client-side.

Async states

• loading
• empty
• error
• retry
• partial

Item identity & owned state

Item key

rowKey — set this when your rows have no id, so selection survives a reorder.

Restorable state

• expandedRowIds
• hiddenColumnKeys
• revealedColumnKeys
• selectedIds
• selectionChange

Bind these to put a saved view back — the open sections, the hidden columns, the selected rows — and read their Change events to store what the user does.

Outputs

<sv-data-table-pro>

Also in this family — SvDataTableProComponent from @styloviz-pro/data-table.

Inputs

Outputs

Wire it to your API

This component is headless about transport: it renders what you give it and reports what the user asks for. Nothing below requires @styloviz/data — it just saves you writing the debounce, the request guard and the retry policy by hand.

<sv-data-table
  [serverSide]="true"
  [rows]="data.items()"
  [loading]="data.loading()"
  [error]="data.error()"
  [totalCount]="data.total()"
  (queryChange)="data.setQuery($event)"
  (retry)="data.reload()"
/>

import { svDataController, createHttpDataSource } from '@styloviz/data';

readonly data = svDataController(
  createHttpDataSource<Row>({ url: '/api/rows' }),
);

• `queryChange` carries an `SvDataQuery` — page, page size, sorts, filters, search and cursor in one object. One handler covers every way the user can change what they are asking for.
• `serverSide` switches **off** the built-in filtering, sorting and paging. Leave it false and the component works entirely from the array you pass — which is what you want for a few hundred rows.
• Normalize failures with `toSvDataError()` from `@styloviz/core`. It derives `retryable` from the status, so a 404 does not get a "Try again" button that can only fail again.

Full walkthrough: Connecting to a backend.

Customization & theming

• Set `[transparent]="true"` to remove the table's own surface fill (root, toolbar, body and rows) so it inherits the background of a glass card or coloured panel — hover/selection and `striped` tints are preserved and the card shadow is dropped; pair with `variant="borderless"`.
• Project rich cell content per column with the `svDtCell` directive: `<ng-template svDtCell="colKey" let-row let-value="value">…</ng-template>` (context exposes `$implicit` = row, `value`, `column`) — falls back to `col.render` text or a badge cell when no template is provided.
• Enable sorting, pagination, selection and bulk actions per table.
• Pro adds column filters, inline editing and expandable rows.
• Set `resizableColumns` to drag-resize columns (per-column `width` and `resizable` opt-out) and `reorderableColumns` to drag- or keyboard-reorder them; changes emit `columnResize` and `columnOrderChange`.
• Set `layout="comparison"` to transpose the table into a Compare-Products grid: the first column supplies each product's name (becoming the column headers) and the remaining columns become feature rows, with boolean values rendered as check / cross icons; `highlightRowId` spotlights the recommended product column.
• **Feature compatibility.** `virtualized` and `groupBy` each replace client pagination rather than combining with it: both render the whole sorted set into one scroller and the pager is hidden, so a `pageSize` alongside either is ignored.
• **Feature compatibility.** `serverSide` turns the client pipeline off entirely — filtering, sorting and paging all pass `rows` through untouched, because the server already did them. There is no double filtering, and equally no client-side fallback: whatever you do not implement server-side does not happen.
• **Feature compatibility.** `serverSide` composes with `groupBy`, but it groups only the page the server sent — a group header reads as a section of this page, not of the dataset.
• **Feature compatibility.** `footerFn`, export and selection all operate on rows in hand. Client-side that is the filtered set; in `serverSide` mode it is the current page, so a footer "Total" is a page total and a select-all selects the page.
• **Feature compatibility.** `layout="comparison"` is a separate rendering path: toolbar, filters, pagination, selection, virtualization, grouping and the footer row do not apply to it. Use it for a fixed handful of products, not as a table mode to toggle.
• **Feature compatibility.** `cardOnMobile` windows on its own `cardRowHeight` under `virtualized`, and deliberately does not group — a collapsible header spanning a card list has no column structure to summarise. Size it to roughly `ceil(visibleColumns / 2) * 46 + 32`px.

Best practices

• Do: Set a stable `rowKey` so selection and row tracking survive re-renders.
• Do: Switch to `serverSide` paging once datasets pass a few thousand rows.
• Don't: Don't render hundreds of unpaged rows — enable `paginated` or virtualize.
• Do: In `serverSide` mode, guard every response with `acceptsResponse(event.requestId)` before applying it. The table renders what the server sent verbatim, so if a slower request lands second the rows and the header disagree and nothing in your own code looks wrong.
• Do: Give an `editable` column a `validate` function. It runs on each keystroke and again on commit, so the message shows while the offending text is still on screen, and an invalid value never reaches `editComplete`.
• Don't: Don't read a `footerFn` total as a dataset total in `serverSide` mode — it sums the page the server sent. The same applies to export and to selection: both act on rows in hand. Ask the server for the aggregate instead.

Accessibility

• Keyboard at scale (X-10): the free table is paginated by default, so its page size is the ceiling. Under `virtualized` the rows are ONE tab stop across the whole dataset: ↑/↓, Home/End, PageUp/PageDown (one viewport, clamped) and typeahead over the first column move the cursor and scroll the window to it; Enter activates the row. Documented ceiling: 2,000 rows rendered at once with neither pagination nor `virtualized` — past it a dev-mode warning fires.
• Focus after a mutation (X-12): if the row holding focus leaves the rendered set — a filter it no longer matches, a host refresh, a delete — focus moves to the same control in the row now at its index, then the row before it, then the table's scroller, and a polite announcement says the row is no longer shown.
• Native table semantics with scoped headers and an accessible table name from `tableTitle`.
• Sortable headers are focusable and operable with Enter/Space, exposing `aria-sort` state.
• Resize handles are focusable separators (`role="separator"`) adjustable with ←/→; reorderable columns move from the keyboard with Ctrl/Cmd + ←/→ on a focused header.
• Selection, pagination and row actions are keyboard reachable; open menus close on Escape.
• Loading regions set `aria-busy`; row-action menus use `role="menu"`/`menuitem`.
• Under `virtualized`, the table declares `aria-rowcount` and stamps every rendered row with its true `aria-rowindex`, so a screen reader announces "row 140 of 241" rather than the size of the window. Header rows, the column-filter row, group headers, expanded detail rows and the footer row all take their place in that numbering; the spacer rows are `aria-hidden` and unnumbered. Both attributes are omitted whenever every row is already in the DOM, so the browser's own count stands and cannot be contradicted.
• A `validate` failure marks the editor `aria-invalid` and points `aria-describedby` at the message, which is also a polite live region — described-by covers arriving at the field, the live region covers an error appearing under a cursor already in it. Enter and blur refuse to commit while it stands; Escape always discards.