I work on ReUI, so keep that in mind. I'll point out where plain TanStack Table is the better call.

What I checked

I compared @tanstack/react-table 9.3.1 with the ReUI data grid as the shadcn CLI served it on 3 Nov 2026. To see exactly what lands in a project, I ran npx shadcn@latest view @reui/data-grid and counted the files.

TanStack Table gives you state, not a table

TanStack Table describes itself as headless, with "full control over markup, styles, and behavior". You get sorting, filtering, grouping, selection and pagination as state and row models. It renders nothing.

For a sortable, paged table that's ideal. You map rows into the shadcn <Table> you already have and you're done in an afternoon.

It gets heavier when the table has to behave like a grid: a menu on each column header, resize handles, pinned columns, keyboard focus moving between cells, virtualization (a separate package, TanStack Virtual), and copy and paste across a range of cells. TanStack Table leaves all of that UI to you on purpose.

ReUI's data grid is that UI, already written

npx shadcn@latest add @reui/data-grid

That adds 12 files and a little over 11,000 lines of TSX to your project. The four biggest files:

That number cuts both ways. It's a lot of grid work you skip. It's also a lot of code that now lives in your repo: you can change any line, and you also maintain every line.

One caveat on the cell selection file: a range selection you write yourself could be far smaller if you skip the edge cases (pinned columns, virtualized rows, translated labels). The count shows what a complete version covers, not what you'd have to write.

You still write the TanStack Table part. The grid renders it:

const table = useTable({
  features: dataGridFeatures,
  data,
  columns,
})

return (
  <DataGrid table={table} recordCount={data.length}>
    <DataGridContainer>
      <DataGridTable />
    </DataGridContainer>
    <DataGridPagination />
  </DataGrid>
)

Your columns, row models and state work the way they do in TanStack Table. Grid behaviour is turned on with tableLayout props instead of built by hand: headerSticky, columnsResizable, columnsPinnable, columnsDraggable, rowsPinnable, cellSelection. On top of that you get infinite scroll, tree and expandable rows, footer rows, inline editing, and one i18n prop for every built-in string.

Four of the free examples:

There are two versions, one on Base UI and one on Radix UI, so use the docs page that matches your project. What it doesn't have: pivot tables and Excel export.

Which one I'd pick

Docs and every example: https://reui.io/docs/components/base/data-grid?utm_source=hashnode&utm_medium=social&utm_campaign=data-grid-comparison

If you've built a grid on TanStack Table, what took the longest: the column menus, virtualization, range selection, or something I didn't list?

We hit this with ReUI, our set of components and blocks for shadcn/ui, so we built an MCP server that gives agents the real registry instead of their memory of it.

What it does

The ReUI MCP server runs at https://mcp.reui.io over Streamable HTTP, so any MCP-capable agent can use it. It does discovery and guidance only:

• Find: search components, examples, blocks and icons in plain language.
• Read: return each component's real API inline, so the agent never has to scrape a docs page.
• Plan and validate: plan a whole page from an intent, and check planned props before any code is written.
• Install: return the exact shadcn CLI command for an item, after checking that it exists.

It never serves source code. Installation stays with the shadcn CLI, which is also where a license key lives for premium items.

Catching invented props before they ship

The tool I like most is validate_usage. The agent sends the component and props it plans to use, and gets a verdict per prop, checked against the indexed API docs. No model, no guessing.

Here is a real call. The agent plans a data grid with table, recordCount, isLoading and sortable, and wants to install c-data-grid-12 and data-grid-pro:

{
  "ok": false,
  "components": [{
    "name": "data-grid",
    "exists": true,
    "props": [
      { "prop": "table", "documented": true },
      { "prop": "recordCount", "documented": true },
      { "prop": "isLoading", "documented": true },
      { "prop": "sortable", "documented": false, "near": ["table", "sortingStrategy"] }
    ]
  }],
  "items": [
    { "name": "c-data-grid-12", "exists": true, "type": "example", "free": true },
    { "name": "data-grid-pro", "exists": false,
      "suggestions": [{ "name": "data-grid-advanced-7", "type": "block" }, { "name": "data-grid", "type": "component" }] }
  ]
}

sortable was the invented prop, and data-grid-pro was the invented package. Both are caught before a single file changes, with a nudge toward what actually exists.

Planning a page, not just a component

compose_page takes an intent like "SaaS billing settings page" and returns an ordered plan: an app shell, a settings block, a form, a dialog, each with a top pick, alternates, preview links and the install sequence. Pass surface: "card" and every section comes from the same design-system surface, so the page doesn't end up as a patchwork of styles.

The four picks from that run:

If a section has no good match, it is listed under unavailableSections instead of being filled with the closest wrong thing. That rule matters more than any ranking: an agent that admits a gap is easier to work with than one that papers over it.

Setup

Claude Code, from your project root:

claude mcp add --transport http reui https://mcp.reui.io

Then run /mcp, pick reui, and approve the sign-in in your browser.

Cursor, in .cursor/mcp.json:

{
  "mcpServers": {
    "reui": { "url": "https://mcp.reui.io" }
  }
}

The first tool call opens a browser to sign in; a free account is created if you don't have one. For CI, create a personal token at Account → MCP and send it as Authorization: Bearer reui_pat_....

A free account covers all the free components and c-* examples. A Pro license adds the premium blocks to search, page plans and installs.

Pair it with the skill

The server answers questions. The ReUI Agent Skill tells the agent which questions to ask, and in what order: plan, find, install, read the API, adapt by reuse, then check. Install it with:

curl -fsSL https://mcp.reui.io/install | node -

In Claude Code it lands in .claude/skills/reui and adds /mcp__reui__build, /mcp__reui__add, /mcp__reui__fix and /mcp__reui__improve.

Try it

Docs and setup for other agents (VS Code, Gemini CLI and more): https://reui.io/docs/mcp?utm_source=hashnode&utm_medium=social&utm_campaign=mcp-article

I'd like to hear where it falls short for you, especially props it still lets through.