Tables are the most "request a feature" component in any DS. Every team needs sorting, filtering, pagination, resizing, selection, expansion, sticky columns, virtualization, server-side modes, CSV export… A single <Table> with 60 props collapses under its own weight.

The right shape: headless core + UI layer

• Headless engine owns state + behavior. Doesn't render anything.
• UI layer renders rows/cells with your DS primitives.

This is exactly what TanStack Table does — and unless you have a strong reason, adopt it instead of building.

Column definitions

const columns = [
  { accessorKey: "name", header: "Name", cell: (info) => info.getValue(), enableSorting: true },
  { accessorKey: "createdAt", header: "Created", cell: (info) => formatDate(info.getValue()) },
  { id: "actions", header: "", cell: ({ row }) => <RowMenu row={row} /> },
];

Each column is a declarative object. Custom cell renderers receive context (row, cell, table).

Feature surface

State ownership

• Controlled: parent owns sorting/filter/pagination state. Required for URL syncing + server-side modes.
• Uncontrolled (initial state) for simple in-memory tables.

Server-side mode

For big datasets, the table can't filter/sort/paginate client-side — switch to manual flags and have the parent fetch:

const { data } = useQuery(["users", sorting, columnFilters, pageIndex],
  () => fetchUsers({ sorting, columnFilters, pageIndex }));

Virtualization

For 10k+ rows, render only visible rows with TanStack Virtual or react-window. Without virtualization, scrolling falls off a cliff around 1–5k rows depending on cell complexity.

Accessibility

• Semantic <table> (not divs) — assistive tech relies on row/column relationships.
• <th scope="col"> and scope="row" for headers.
• Sortable headers as <button> inside <th> with aria-sort="ascending|descending|none".
• Selection: role="row" with aria-selected, plus selection checkboxes labeled.
• Keyboard: arrow keys for grid navigation on data-grids (role="grid") — but only adopt if you implement it correctly.

Anti-patterns

• One mega <Table> with props for every feature — composability dies.
• Re-rendering the whole table on every cell change.
• DIY virtualization when libraries exist.
• Building a server-side and client-side variant as separate components.

What to expose

<Table
  columns={columns}
  data={data}
  state={{ sorting, columnFilters, pagination }}
  onStateChange={...}
  manualSorting
  manualPagination
>
  {/* slots: header, body, empty, loading, footer */}
</Table>

Slots for empty / loading / footer keep the component composable.

Interview framing

"Build on a headless engine like TanStack Table — it owns state for sorting, filtering, pagination, selection, expansion. The UI layer is yours, themed by the design system. Support controlled state so parents can URL-sync or run server-side modes. Virtualize for long lists. Use semantic <table> elements with proper ARIA. Avoid the god-component anti-pattern — expose slots and let consumers compose. The hardest engineering work is server-side modes, virtualization, and a11y — not the rendering."