TanStack Table

TanStack Table is a headless, TypeScript-first library for building tables and datagrids. It ships zero UI markup and instead computes state and row/column/header models for you to render however you like — HTML tables, divs, or any component library — while handling sorting, filtering, grouping, pagination, row selection, and column sizing/pinning as opt-in plugins.

What You Get

• A framework-agnostic core (@tanstack/table-core) plus adapters for React, Vue, Solid, Svelte, Angular, and Qwik that all share the same API
• Opt-in feature plugins for sorting, column/global filtering, grouping, row/column pinning, column sizing, expanding, pagination, and row selection
• Full TypeScript generics so column value types, accessors, and cell renderers are inferred end-to-end with no codegen step
• flexRender() and a fully headless rendering model, so you control every DOM element and can style with Tailwind, CSS Modules, or any component library
• Composable row/column/header models (getCoreRowModel, getSortedRowModel, getFilteredRowModel, etc.) that you assemble a la carte to keep bundle size tied to what you use

Common Use Cases

• Building an admin dashboard datagrid with sortable, filterable, paginated columns without shipping a heavyweight UI kit
• Adding client-side or server-side pagination and sorting to a data table backed by a REST or GraphQL API
• Implementing row selection with checkboxes for bulk-action toolbars (delete, export, assign)
• Rendering expandable/nested rows for hierarchical data (org charts, nested line items, grouped transactions)
• Building a spreadsheet-like editable grid with per-cell editing and controlled column sizing/pinning

Under The Hood

Architecture TanStack Table’s architecture cleanly separates a framework-agnostic core (@tanstack/table-core) from thin per-framework adapters (@tanstack/react-table, vue-table, solid-table, etc.). The core’s createTable() (packages/table-core/src/core/table.ts) composes a fixed list of built-in TableFeature plugins — Headers, ColumnVisibility, ColumnOrdering, ColumnPinning, ColumnFaceting, ColumnFiltering, GlobalFaceting, GlobalFiltering, RowSorting, ColumnGrouping, RowExpanding, RowPagination, RowPinning, RowSelection, and ColumnSizing (table.ts:41-57) — each contributing its own state slice, default options, and instance methods via a shared TableFeature interface (packages/table-core/src/features/*.ts). Rows, columns, cells, and headers (packages/table-core/src/core/{row,column,cell,headers}.ts) are lazily computed and memoized into row models so re-renders only recompute what changed. The React binding (packages/react-table/src/index.tsx) is intentionally thin: useReactTable() wraps createTable() in a single useState ref, mirrors table state into React state via onStateChange, and re-merges user-controlled state on every render — the framework adapter owns none of the table logic itself.

Tech Stack The published 8.21.3 line is pure TypeScript with zero runtime dependencies outside the internal @tanstack/table-core workspace package (packages/react-table/package.json) — no DOM libraries, no rendering engine, and no CSS. table-core builds via Rollup with a separate tsc —noEmit type-check step, and the monorepo is orchestrated with pnpm workspaces plus Nx (test:lib, test:types, build targets). Tests run on Vitest (packages/table-core/tests/.test.ts, packages/react-table/tests/**/.test.tsx). The public API is fully typed via TypeScript generics (RowData, ColumnDef<TData>), giving column-value type inference end-to-end without codegen.

Code Quality Test coverage is present but modest relative to the codebase’s size: table-core’s tests/ directory (RowSelection.test.ts, RowPinning.test.ts, getGroupedRowModel.test.ts, utils/document.test.ts) covers roughly 674 lines against ~8,450 lines of core source, and react-table adds a handful of integration tests (core.test.tsx, RowSelection.test.tsx, Visibility.test.tsx) with snapshot coverage. Error handling is minimal by design — the library trusts caller-supplied column defs and data rather than validating them at runtime, leaning on TypeScript to catch misuse at compile time instead. Naming is consistent across the whole surface (getRowModel, use, on*Change), and the plugin/feature pattern keeps each concern in its own file, which limits blast radius when reading or modifying a single feature.

API Design Getting started requires a single hook call — useReactTable({ data, columns, getCoreRowModel: getCoreRowModel() }) — after which every other feature (sorting, filtering, pagination) is opted into by adding one more getXRowModel() function, keeping API surface proportional to what’s actually used. Because the library is headless, there is real boilerplate: consumers must write their own table/row/cell markup and wire flexRender() for header/cell content, which raises the initial learning curve compared to a batteries-included datagrid. In exchange, naming is highly consistent (table.getHeaderGroups(), row.getVisibleCells(), column.getCanSort()) and documentation plus dozens of runnable examples under examples/react cover nearly every feature combination, offsetting the extra setup work once a developer is past the first table.