Drivn vs shadcn/ui — Data Table Compared

shadcn/ui hands you a recipe; Drivn hands you a component. With shadcn you import useReactTable, getCoreRowModel, optionally getSortedRowModel and getPaginationRowModel, declare columns via createColumnHelper, call useReactTable({ data, columns, ... }), then render the <Table> markup using table.getHeaderGroups().map(...) and table.getRowModel().rows.map(...). Each table you build pays that wiring cost again. Drivn collapses that surface to one JSX element — <DataTable data={users} columns={columns} rowKey="id" sortable selectable /> — and the column definition is plain data: { id, header, cell, sortable, align, width }. The full prop set lives in the Data Table docs. For applications where every list view becomes a table, the difference is the table being a one-liner instead of a fifty-line block.

shadcn/ui's table recipe sits on top of @tanstack/react-table (formerly react-table) — a generic table runtime that ships its own column model, row model, and feature plugins. The library is roughly thirty kilobytes of vendor JavaScript on top of React and is built to support every pattern the ecosystem has invented for tables: faceted filters, column pinning, virtualization adapters, expanded rows, grouping. Drivn ships none of that. The DataTable file imports React, Table, Checkbox, Skeleton, Pagination, and the cn utility — that is the entire dependency list. Sorting is a useMemo over the data array that compares by the column id with localeCompare for strings and subtraction for numbers. Selection is a useState<Set<string>>. The trade is honest: TanStack covers the long tail; Drivn covers the eighty-percent table you ship in product views. If your application already pays the TanStack cost for one critical grid, you can keep using shadcn there and reach for Drivn for the rest. See the Drivn CLI for how to add it to a single page without touching the rest of the project.

Selecting rows is the place TanStack and Drivn end up at almost the same UX with very different code. In the TanStack recipe you opt into row selection by adding a custom column whose header renders a <Checkbox> bound to table.getIsAllPageRowsSelected() and table.toggleAllPageRowsSelected, and whose cell renders a per-row <Checkbox> bound to row.getIsSelected() and row.toggleSelected. The selection state lives inside the TanStack table instance and you read it via table.getSelectedRowModel().rows. Drivn moves both checkboxes and the indeterminate state into the component. Pass selectable and the leading select column appears with a header Checkbox whose indeterminate flag is set by a useEffect that compares selected.size against the visible row keys. The onSelectionChange callback hands you a Set<string> of selected row keys directly. The visual primitive is the same Drivn Checkbox used everywhere else, and the indeterminate ref pattern is the same one the source documents.

Two states that almost every product table needs are not in the TanStack recipe by default — you render a Skeleton row yourself when isLoading, and you render a fallback <TableRow> with a <TableCell colSpan={...}> when data.length === 0. Drivn bakes both into the component. Pass loading and the body renders five rows of Skeleton whose width matches each column's width prop, falling back to 60% when no width is set. When the data array is empty, the body renders a centered "No results." message in a single full-span cell. Both behaviors live inside the conditional render in the source — the loading branch comes first, the empty branch second, the data branch third — and you can extend either by editing the component file. The states pair naturally with the Skeleton component used across Drivn for any deferred render.

Pagination is the second half of any table that lists more than fifty rows. The TanStack approach gives you getPaginationRowModel, table.getState().pagination, table.previousPage(), table.nextPage(), and you wire those to a footer with two buttons and a "Page x of y" label. Drivn ships DataTable.Pagination as a sub-component on the same object via Object.assign(DataTableRoot, { Pagination: DataTablePagination }), so you write <DataTable.Pagination page={page} pageCount={pageCount} onPageChange={setPage} /> inside the footer prop. The component renders the Page x of y label plus a Pagination Previous and Next pair with aria-disabled set when the boundaries hit. Page state lives in your component, which keeps the data-fetching pattern explicit — the table does not own the page; you do. The trade is the same as elsewhere: TanStack ships more rope (jumping to a page, page-size selectors), Drivn ships the common path with a smaller surface.