Table

At a glance

Thirty-six sample rows in the default renderer: search, selection, column controls and paging are props. Sort a column, select rows, hide a column.

What Svelte Lean Table is

Most tables in an application need identity, sorting, a search box and a pager. Some need selection and expansion. A few need editing, grouping, ranges and clipboard, or ten thousand rows. Svelte Lean Table serves the first group without carrying the last: the renderer contains the semantic table and the interactions that fit in props, and everything larger is a module that enters a build only when it is imported.

Supporting a feature should not mean shipping the feature. The table-basic consumer fixture builds a page with DataTable and its stylesheet in production mode and asserts, in the module graph, that the grouping, pivot, clipboard, export, server and state modules are absent. The Svelte Lean chunk of that build is 16829 B brotli (18900 B gzip), with Svelte's own runtime recorded separately.

The output is a <table> with the elements and attributes assistive technology expects; no cell is a component instance unless the application supplies a snippet; state is serializable and controlled from the outside; every string is a message; server rendering is tested. The engine underneath, createTable(), is exported for renderers of your own.

<script lang="ts">
	import { DataTable, type Column } from '@svelte-lean/table';
	import '@svelte-lean/table/style.css';

	type Member = { id: number; name: string; revenue: number };
	const data: Member[] = [
		{ id: 1, name: 'Amara Okafor', revenue: 1200 },
		{ id: 2, name: 'Jonas Lindqvist', revenue: 9119 }
	];
	const columns: Column<Member>[] = [
		{ id: 'name', header: 'Member' },
		{ id: 'revenue', header: 'Revenue', align: 'end' }
	];
</script>

<DataTable {data} {columns} getRowId={(row) => row.id} />

Capability levels

One product, four levels. A table does not pay for a level it does not use, and the levels are props and imports, not different components.

Build profiles

Two profiles, read from measurement files. The first is a real consumer build; the second is what a grid adds, per entry, because no fixture builds that combination yet.

Entry points and measured sizes

Every entry of @svelte-lean/table as measured by yarn size into packages/table/artifacts/size.json. Budgets are enforced in CI and sit above the measured value.

Each entry bundled independently with esbuild (bundle + minify, ESM); shared code is counted per entry here and de-duplicated by consumer bundlers. Svelte peer runtime excluded. gzip level 9 / brotli quality 11 (node:zlib). Budgets are gzip.

Timings

Rows are not virtualized, so a large table costs what its DOM costs. These are the medians the playground benchmark recorded with every row in the document; they are read from the benchmark file with the environment of that run and compare the table with itself, never with another library. Without a committed run the cells read "not measured".

Environment: chromium 153.0.8010.53, Apple M2, darwin 27.0.0, Node v22.23.3, production build, run 2026-09-27. Method and reproduction on Methodology.

Specimens

The 31 examples of the previous site, in their five groups, each living on the page of its feature. Every one is a live DataTable with its Svelte source.

Essentials

• Basic table — The smallest useful table: typed data, typed columns and stable row identity.
• Custom cells — Render product-specific content with typed Svelte snippets while the table keeps layout and semantics.
• Sorting — Single and multi-column sorting with visible priority and controlled state.
• Filtering and search — Combine global search with per-column filters and custom operators.
• Pagination — Client or server pagination with controlled page index and page size.
• Row selection — Single or multiple selection, disabled records and page or filtered select-all scope.

Layout

• Density and borders — Switch density, stripes and cell borders without changing the row model.
• Fixed header — Keep headers visible inside a constrained scrolling surface.
• Fixed columns — Pin identity and action columns while wide records scroll horizontally.
• Grouped headers — Describe multi-level headers with nested column definitions.
• Column visibility — Let users hide fields while protecting required columns.
• Resize and reorder — Resize with pointer or keyboard and persist an explicit column order.
• Ellipsis — Constrain long values with optional native title disclosure.
• Cell spans — Merge adjacent cells with row and column span callbacks.
• Right-to-left — Mirror pinned columns, navigation and resize behavior with one direction prop.

Rows

• Expandable rows — Reveal one details region per record and control which rows may expand.
• Tree data — Render nested records through getSubRows with configurable indentation.
• Row grouping — Derive group rows and aggregates with the optional grouping entry point.
• Row reordering — Move rows through a controlled callback without hidden data mutation.
• Row events — Handle click, double-click, context menu and declarative cell actions.
• Row animation — Animate application-owned row insertion and removal while respecting reduced motion.

Workflows

• Editing and history — Validate cell edits, persist them in the application and add undo only when needed.
• Range and clipboard — Select a rectangular range and translate it to or from tab-delimited spreadsheet data.
• CSV export — Export visible data with correct quoting and spreadsheet-formula protection.
• Server data — Control loading, errors, row counts and stale requests without coupling the table to a transport.
• Persisted state — Serialize presentation state and safely restore only columns that still exist.
• Loading and empty — Make waiting, retrying and zero-result states part of the component contract.
• Localization — Replace every built-in message and switch layout direction independently.

Analysis

• Summaries — Render totals aligned with visible and pinned columns.
• Pivot — Turn long-form records into a compact cross-tab using an optional pure helper.
• Performance — Repeatable size and browser measurements with the limits stated beside every number.

Compared with a grid

A grid library starts from the grid: virtualized rows, a cell model, an editing engine, and a keyboard runtime that every table pays for. Svelte Lean Table starts from the table and treats the grid as a level the application reaches by adding props and imports, with the semantics of a native table kept at every level. Where a project needs virtualized rows today, this package does not provide them and says so.

Below the component

createTable() is the engine the renderer is built on: it derives the row model, the visible columns and the header rows from getters over your state and exposes every transition. @svelte-lean/table/core is the pure model without Svelte, for tests and servers. Both are documented under Engine in the API reference.

Read next

• Getting started
• Data Grid
• API reference