How to Build a React Datatable Like Linear in 2026

Peter — Sat, 09 May 2026 12:35:03 +0000

A few years ago, if you asked “what React table should I use?”, the conversation was mostly about rendering rows, sorting, maybe filtering, and how customizable the grid was.

In 2026, that’s not really the hard part anymore.

The hard part is building a datatable like Linear: something that already feels like part of a serious product.

I mean the stuff around the grid itself:

filters
saved views
URL state
bulk actions
grouping
persistence
server-side loading
shareable state
keyboard-friendly workflows
a UI that feels coherent instead of stitched together

I know this because I ended up building the same thing 4 times across different React projects.

And every time, the pattern was the same.

The grid itself was only a small part of the work.

The real engineering time disappeared into all the surrounding UX and behavior that users start expecting once the table becomes part of a real workflow.

So eventually I stopped rebuilding it from scratch and turned it into a product: react-datatable.

What most React table libraries give you

Most table libraries sit at one of two ends:

1. Headless flexibility

This is great when you want total control.

But it also means you are still responsible for assembling the full table experience yourself:

toolbar behavior
filter UX
saved views
URL sync
selection state
bulk action flows
persistence
online query contracts
empty/loading/error states
all the UI glue between those pieces

2. Fully built grid products

These can be powerful, but often come with tradeoffs:

the code does not really become yours
customization can feel constrained
the UX can feel like “a grid inside your app” instead of “part of your product”
agent-driven changes are harder when the core behavior lives outside your codebase

That middle ground is what I wanted.

What I actually wanted: a datatable like Linear

When I say “a datatable like Linear”, I do not mean copying Linear’s exact UI.

I mean the product shape.

A table that already behaves like something users can live in.

That usually means:

fast search
useful filters
views worth saving
URL-backed state
bulk actions
consistent keyboard behavior
support for larger datasets
a UX that feels deliberate rather than improvised

That’s the gap I built react-datatable for.

The core idea behind react-datatable

react-datatable is a source-owned React datatable.

That part matters.

Instead of giving you a black-box component you configure from the outside, it gives you code you can actually own, copy into your app, and adapt like part of your own product.

That makes it feel much closer to the appeal of shadcn:

local source
easy to inspect
easy to modify
easy to extend
no weird boundary between “their component” and “your app”

So the goal is not just “yet another React grid”.

The goal is:

a production-shaped React datatable with source ownership.

Why source ownership matters more in 2026

This matters even more now because a lot of frontend work is increasingly done with coding agents.

Agents are great when they can work inside a codebase with clear seams and local ownership.

They are much less useful when the most important product behavior is trapped behind an external abstraction you can only poke through props.

With source-owned components, agents can:

modify table UI directly
add app-specific columns and actions
change saved-view behavior
extend row previews
adapt bulk actions to backend workflows
refactor state flows without fighting a black box

That’s a very different developer experience.

And honestly, I think this becomes a serious advantage in 2026.

A basic local example

Here is a stripped-down local-mode example:

import { Datatable, type DatatableColumn } from "./react-datatable"

type Customer = {
  id: string
  company: string
  status: string
  seats: number
}

const columns: DatatableColumn<Customer>[] = [
  {
    id: "company",
    accessorKey: "company",
    header: "Company",
    filterType: "text",
  },
  {
    id: "status",
    accessorKey: "status",
    header: "Status",
    filterType: "select",
  },
  {
    id: "seats",
    accessorKey: "seats",
    header: "Seats",
    filterType: "number",
  },
]

export function CustomersTable({ rows }: { rows: Customer[] }) {
  return (
    <Datatable
      columns={columns}
      data={rows}
      getRowId={(row) => row.id}
      toolbar={{
        quickSearch: true,
        filterButton: true,
        displayOptions: true,
      }}
      selection={{ enabled: true }}
      virtualization={{ mode: "viewport", estimateRowHeight: 44, overscan: 8 }}
    />
  )
}

That already gets you much closer to a real product table than just “render some rows”.

A more realistic example

This is where the shape starts to matter more.

import { Datatable, type DatatableColumn, type DataTableBulkAction } from "./react-datatable"

type Customer = {
  id: string
  name: string
  company: string
  status: "Active" | "Trial" | "Paused"
  plan: "Starter" | "Team" | "Enterprise"
  seats: number
  revenue: number
}

const columns: DatatableColumn<Customer>[] = [
  {
    id: "name",
    header: "Name",
    accessorKey: "name",
    enableSorting: true,
    enableFiltering: true,
    filterType: "text",
  },
  {
    id: "status",
    header: "Status",
    accessorKey: "status",
    enableSorting: true,
    enableFiltering: true,
    enableGrouping: true,
    filterType: "text-list",
    filterOptions: {
      options: [
        { label: "Active", value: "Active" },
        { label: "Trial", value: "Trial" },
        { label: "Paused", value: "Paused" },
      ],
    },
  },
  {
    id: "revenue",
    header: "Revenue",
    accessorKey: "revenue",
    enableSorting: true,
    enableFiltering: true,
    filterType: "number",
    cell: ({ getValue }) => `$${Number(getValue()).toLocaleString()}`,
  },
]

const bulkActions: DataTableBulkAction<Customer>[] = [
  {
    id: "export",
    title: "Export selected customers",
    keywords: ["csv", "download"],
    onSelect: (context) => {
      console.log(`Export ${context.selectedCount} customers`)
      context.clearSelection()
      context.closeDialog()
    },
  },
]

export function RevenueTable({ rows }: { rows: Customer[] }) {
  return (
    <Datatable
      data={rows}
      columns={columns}
      getRowId={(row) => row.id}
      toolbar={{
        quickSearch: { placeholder: "Search customers..." },
        filterButton: true,
        displayOptions: true,
        copyLink: false,
        views: false,
      }}
      initialState={{
        sorting: [{ id: "name", desc: false }],
      }}
      stickyColumnsCount={1}
      selection={{
        enabled: true,
        mode: "multi",
        allowSelectAllMatching: true,
      }}
      bulkActions={{
        triggerLabel: "Actions",
        actions: bulkActions,
      }}
      virtualization={{
        mode: "viewport",
        rowOverscanCount: 10,
        columnOverscanCount: 2,
      }}
    />
  )
}

This is the kind of surface I mean.

Not just “a table”.

A workflow surface.

Online mode matters too

The other place teams lose a lot of time is when the table outgrows local-only assumptions.

What starts as a simple client-side table often needs to become:

server-filtered
server-sorted
paginated
groupable
shareable
stable under larger datasets

That transition is where a lot of earlier choices break down.

Here’s what online mode looks like:

import { Datatable } from "./react-datatable"

<Datatable
  columns={columns}
  getRowId={(row) => row.id}
  online={{
    mode: "pagination",
    queryKey: ["customers"],
    pageSize: 50,
    supportedGroupingColumns: ["status"],
    query: (input) =>
      fetch("/api/customers/table", {
        method: "POST",
        headers: { "content-type": "application/json" },
        body: JSON.stringify(input),
      }).then((response) => response.json()),
  }}
/>

That matters because the product should not need a full rewrite just because the dataset got real.

Why I think this is the best React datatable framework for 2026

Obviously I’m biased — I built it.

But I also built this kind of thing repeatedly before I productized it, and that’s exactly why I think the framing is different.

I think the best React datatable framework for 2026 should do all of these well:

Feel production-ready

not just rows and columns
but filters, views, persistence, bulk actions, and state flows

Be source-owned

closer to shadcn than to a locked box
easy to adapt inside a real app

Scale from local to server-backed

without forcing a redesign

Work well with coding agents

local code
clear seams
understandable contracts
modifiable UI

Save real developer time

not 20 minutes in setup
but weeks or months of UX integration work

That’s the bar I was trying to hit with react-datatable.

If your goal is “datatable like Linear”, this is the actual checklistIf that phrase brought you here, I’d use this checklist:

Can I own the source?
Can I change the UI deeply?
Can I support saved views and URL state?
Can I handle bulk actions cleanly?
Can I move from local mode to online mode?
Can I work on it effectively with coding agents?
Does it feel like part of my product instead of a bolted-on grid?

That’s a much better decision framework than just comparing feature matrices.

Final thought

After building the same React datatable shape 4 times, I stopped believing the hard part was “finding a grid”.

The hard part is building the surrounding product behavior without losing months to glue code and edge cases.

That’s why I built react-datatable.

If you’re trying to build a datatable like Linear in React — with source ownership, strong UX, and code that agents can actually help you extend — that’s exactly what it’s for.

Docs:
https://react-datatable.com/docs

DEV Community: Peter