Design a Data Grid

Production data grids routinely render datasets of tens of thousands to millions of rows while holding 60 fps scroll, sub-second sorting, and Excel-style keyboard navigation. This article reverse-engineers how the four mainstream architectures — headless, full-featured, canvas-based, and React-integrated — get there, where each one breaks, and how to choose.

The forcing function is simple: browsers slow down quickly past a few thousand DOM nodes, and Lighthouse already raises an “excessive DOM” error at ~1,400 body nodes (web.dev, Chrome Lighthouse). A naive 100,000-row × 20-column grid would mint 2 million cells; every serious grid library exists to keep the working set far smaller than that without lying to the user about the dataset size.

Abstract

Data grids are constrained-optimization problems balancing DOM size, memory, render latency, and feature surface:

• Virtualization is non-negotiable past a few hundred rows, in both axes once column counts grow. Fixed-height virtualization is O(1) for visible-range math; variable-height needs a height cache, an estimator, anchor-preservation, and a ResizeObserver-driven measureElement to avoid scroll jumps (TanStack Virtual Virtualizer).
• Four architectures dominate. Headless (TanStack Table — you own the markup), full-featured (AG Grid — batteries included), canvas-based (Google Sheets / Docs — bypass the DOM), and React-integrated (MUI X DataGrid — virtualization built in).
• Row models cap your scale. Client-side row models work up to ~100K rows in memory; infinite, server-side, and viewport row models push that to millions by fetching pages, groups, or visible windows on demand.
• Pinning is two-dimensional. Frozen columns split the grid into three vertically synced scroll regions; frozen rows (sticky headers, totals footers) extend that into a nine-region layout that has to coordinate selection, focus, and keyboard navigation.
• Editing is a state machine. Cells move through view → edit → validating → pending → committed/reverted. Cell, row, and full-row commit modes differ only in when the boundary fires.
• Paint cost is paid in transform, content-visibility, and CSS containment. The cheapest scroll uses GPU-composited translate3d rows, content-visibility: auto with contain-intrinsic-size for off-screen sub-trees, and contain: layout paint to stop dirty regions from escaping a row (web.dev content-visibility, W3C CSS Containment Module).
• Clipboard, undo, and a11y do not come free. Excel-style copy/paste, multi-step undo, ARIA grid roles, roving tabindex, and aria-rowindex updates are the things teams skip first and regret first.

The right choice falls out of dataset size, feature breadth, and how much rendering control your design system needs.

The Challenge

Browser Constraints

Grids stress browsers along axes most UIs never touch:

The 16 ms budget evaporates fast: a single forced reflow during scroll can blow the frame all by itself, before you have written a single cell.

Scale Factors

User Experience Requirements

• Perceived latency. Scroll must feel instant. Users notice >100 ms of delay on direct manipulation (web.dev RAIL).
• Sort/filter responsiveness. Aim for under 500 ms for in-memory operations; show progressive feedback for server calls.
• Edit feedback. Cell changes must reflect immediately; reconcile server sync asynchronously.
• Keyboard navigation. Power users expect Excel-style movement without leaving the keyboard, which is also what the WAI-ARIA Grid pattern prescribes.

Mental Model

Three layers, in order:

1. Data layer. Owns the source of truth (in-memory, fetched, or streamed) and the transforms applied to it (sort, filter, group, aggregate).
2. Virtualization layer. Translates scroll position into a small set of “rows that should currently exist in the DOM” and keeps a recycled pool of node instances.
3. Render layer. Splits visually into a fixed header, a scrollable body, and 0-2 pinned column regions that share vertical scroll with the body.

Every grid library in this article is some flavor of those three layers wired together. The variation is in which layer the library owns and which layer it hands you:

• TanStack Table owns the data layer and hands you everything else.
• AG Grid owns all three.
• Canvas-based grids own all three but replace the render layer with a <canvas>.
• MUI X DataGrid owns all three but renders DOM nodes for visible cells.

Design Paths

Path 1: Headless Library (TanStack Table)

Architecture.

TanStack Table v8 (the rewrite formerly known as React Table) ships table logic — state, row models, sorting, filtering, grouping, pagination — without any rendering. The core (@tanstack/table-core) is framework-agnostic; thin adapters wrap it for React, Vue, Solid, Svelte, and Qwik (Migrating to v8).

How it works.

The library exposes hooks (useReactTable) that return a table instance. You destructure methods like getHeaderGroups(), getRowModel(), and getVisibleCells() to build your own markup. Sorting, filtering, and pagination are opt-in row models you import and configure.

Show 5 hidden lines6} from "@tanstack/react-table"78const table = useReactTable({9  data,10  columns,11  getCoreRowModel: getCoreRowModel(),12  getSortedRowModel: getSortedRowModel(),13  state: { sorting },14  onSortingChange: setSorting,15})1617return (18  <table>19    <tbody>20      {table.getRowModel().rows.map((row) => (21        <tr key={row.id}>22          {row.getVisibleCells().map((cell) => (23            <td key={cell.id}>{flexRender(cell.column.columnDef.cell, cell.getContext())}</td>24          ))}Show 5 hidden lines

Best for.

• Teams wanting full control over markup and styling.
• Design systems with non-negotiable HTML structure.
• Apps where bundle size is a hard constraint — @tanstack/react-table ships at ~14.6 KB minified + gzipped on Bundlephobia (@tanstack/react-table).
• Projects already using a virtualization library (react-window, @tanstack/react-virtual).

Implementation complexity.

Trade-offs vs other paths.

• Pros: smallest core bundle, full markup control, framework-agnostic engine.
• Cons: no built-in virtualization, more code to write, accessibility lives entirely with you.

Path 2: Full-Featured Framework (AG Grid)

Architecture.

AG Grid bundles virtualization, sorting, filtering, grouping, pivoting, Excel export, and an enterprise feature set on top of a vanilla-JS core wrapped per framework.

How it works.

AG Grid ships four row models for different scale and update profiles (AG Grid Row Models):

1. Client-Side Row Model (Community, default). All data into memory. Full sort, filter, group, aggregate in the browser. Comfortable up to ~100K rows due to virtualization.
2. Infinite Row Model (Community). Lazy-loads blocks of rows as the user scrolls. Best for large flat datasets where loading the whole set into the client is impractical. AG Grid recommends Enterprise users prefer Server-Side instead.
3. Server-Side Row Model (Enterprise). Extends infinite scrolling with server-driven grouping and aggregation. Handles millions of rows by fetching grouped data on demand (Server-Side docs).
4. Viewport Row Model (Enterprise). The server controls exactly which rows are visible — useful when the data is updated faster than the client could render the full set, e.g. tick-by-tick market data (Viewport docs).

These map onto three different delivery modes — collapsed into one table so you stop conflating them:

The server-side row model layers grouping and aggregation on top of paged delivery; the viewport row model is push delivery scoped to the visible window.

Show 3 hidden lines45const gridOptions = {6  rowModelType: "serverSide",7  serverSideDatasource: {8    getRows: (params) => {9      // Server handles sorting, filtering, grouping10      fetch("/api/rows", {11        method: "POST",12        body: JSON.stringify({13          startRow: params.request.startRow,14          endRow: params.request.endRow,15          sortModel: params.request.sortModel,16          filterModel: params.request.filterModel,17          groupKeys: params.request.groupKeys,18        }),19      })Show 5 hidden lines

Best for.

• Enterprise applications with complex requirements (pivoting, Excel export, range selection).
• Teams that prefer configuration over hand-rolled UI.
• Applications that need server-side data operations out of the box.
• Financial and analytics dashboards with continuous updates.

Implementation complexity.

Trade-offs vs other paths.

• Pros: comprehensive feature set, excellent docs, battle-tested at scale.
• Cons: large bundle even after tree-shaking, theming requires understanding their architecture, enterprise license cost.

Path 3: Canvas-Based Rendering (Custom or Specialized)

Architecture.

Canvas grids draw cells directly to a <canvas> 2D context, bypassing the DOM for the cell area. This eliminates per-cell layout cost but means re-implementing text rendering, selection, scrollbars, hit-testing, copy/paste, and find-in-page.

How it works.

The render loop runs on requestAnimationFrame. On each frame:

1. Calculate which rows and columns are visible from the scroll position.
2. Clear the canvas (or just the dirty regions).
3. Draw cell backgrounds, then text, then borders.
4. Draw selection overlays.
5. Schedule the next frame if scrolling.

Text input requires overlay <input> elements positioned over the canvas. Mouse interaction requires hit-testing coordinates against cell boundaries. Accessibility requires a parallel DOM structure that mirrors what the canvas paints.

Best for.

• Spreadsheet apps that need 100K+ visible cells simultaneously.
• Apps where DOM performance has been measured as the bottleneck.
• Teams with prior graphics-programming experience.
• Custom in-cell visualizations (sparklines, heatmaps, waveforms).

Implementation complexity.

Trade-offs vs other paths.

• Pros: best raw rendering throughput, full visual control, no DOM-node ceiling.
• Cons: accessibility is hard, every browser feature (find, copy, translate, IME) must be re-implemented, large engineering investment.

Path 4: React-Integrated with Built-In Virtualization (MUI X DataGrid)

Architecture.

MUI X DataGrid keeps real DOM elements but renders only those for visible cells, bridging canvas-style throughput and DOM-style accessibility.

How it works.

Row virtualization renders only rows in the viewport plus a configurable pixel-buffer overscan. Column virtualization renders columns within a similar pixel buffer. The grid maintains scroll position with a combination of:

• Absolute positioning of the visible rows
• A spacer element sized to the total scrollable height
• Transform translations for smooth updates during scroll

The current API uses pixel-based buffer props (rowBufferPx, columnBufferPx); these replaced the older count-based rowBuffer / columnBuffer props (MUI X virtualization docs).

Show 4 hidden lines5  rows,6  columns,7  // Pixel-based buffers above and below / left and right of the viewport.8  rowBufferPx: 200,9  columnBufferPx: 150,10  // Disable only for tests (e.g. jsdom); destroys performance on real data.11  // disableVirtualization: true,12}1314// The Community tier caps row virtualization at 100 rows.15// Pro and Premium remove the cap.

Best for.

• React applications already on Material UI.
• Teams that want virtualization without writing it.
• Medium-scale grids — thousands to tens of thousands of rows.
• Apps that want sane defaults more than maximum customization.

Implementation complexity.

Trade-offs vs other paths.

• Pros: balanced features and bundle, virtualization included, React-idiomatic API.
• Cons: tied to the MUI ecosystem, Community tier has hard limits, less customizable than headless.

Decision Matrix

Virtualization Deep Dive

Virtualization is the foundation of grid performance — every architecture above ultimately rests on some form of it. The variants differ in how they translate scroll position to a visible-row range and how they recycle the DOM.

Fixed-Height Virtualization

When all rows have identical height, the visible-range math is constant time:

1const itemHeight = 35 // pixels2const scrollTop = 15003const containerHeight = 50045const startIndex = Math.floor(scrollTop / itemHeight)6const endIndex = Math.min(7  startIndex + Math.ceil(containerHeight / itemHeight) + 1,8  totalRows,9)1011const visibleRows = rows.slice(startIndex, endIndex)12const offsetY = startIndex * itemHeight

Scroll performance is optimal because:

• No DOM measurement during scroll
• Direct index calculation, no binary search
• A single, stable total-height calculation

Use when: log viewers, data tables with uniform content, lists of records of the same shape.

Variable-Height Virtualization

Real content varies. Social feeds, rich-text editors, expandable rows, and any cell with wrapped text need dynamic-height handling:

1const heightCache = new Map<number, number>()2const estimatedHeight = 5034function getRowOffset(index: number): number {5  let offset = 06  for (let i = 0; i < index; i++) {7    offset += heightCache.get(i) ?? estimatedHeight8  }9  return offset10}1112function findStartIndex(scrollTop: number): number {13  let low = 0,14    high = totalRows - 115  while (low < high) {16    const mid = Math.floor((low + high) / 2)17    if (getRowOffset(mid) < scrollTop) {18      low = mid + 119    } else {20      high = mid21    }22  }23  return low24}

The challenges:

1. Scroll jump. When estimates are wrong, the total scrollable height changes as items render, and the scrollbar visibly jumps.
2. Measurement timing. You cannot measure until you render, but you need heights to know what to render.
3. Memory overhead. The height cache grows with the dataset.

Mitigations:

• Overscan. Render extra rows above and below the viewport so newly visible rows are already measured.
• Estimate refinement. Update the running estimate as you measure more items.
• Anchor preservation. When the total height changes, adjust scroll position to keep the visually anchored content stable.
• ResizeObserver-driven re-measurement. TanStack Virtual exposes virtualizer.measureElement (attached to each row’s ref) which observes the rendered element via ResizeObserver and rewrites the height cache without a layout thrash (TanStack Virtual API). react-window delegates to a user-supplied itemSize and offers VariableSizeList with explicit resetAfterIndex invalidation.

Column Virtualization

Wide grids need horizontal virtualization. MUI X DataGrid renders columns within a configurable pixel buffer (columnBufferPx, default ~150 px) of the visible region:

1const scrollLeft = container.scrollLeft2const containerWidth = container.clientWidth34const visibleStart = scrollLeft - columnBuffer5const visibleEnd = scrollLeft + containerWidth + columnBuffer67const visibleColumns = columns.filter((col, index) => {8  const colStart = getColumnOffset(index)9  const colEnd = colStart + col.width10  return colEnd >= visibleStart && colStart <= visibleEnd11})

Column virtualization composes with pinned columns: pinned columns are always rendered regardless of horizontal scroll position.

Overscan Strategy

Overscan renders items beyond the visible region to mask blank flashes during fast scrolling:

react-window exposes overscanCount (default 1, applied in the scroll direction) (react-window list props). MUI X exposes rowBufferPx and columnBufferPx in pixels (MUI X virtualization).

Column and Row Features

Sorting Implementation

Client-side sorting is straightforward but blocks the main thread:

1function sortRows(rows: Row[], sortKey: string, direction: "asc" | "desc") {2  return [...rows].sort((a, b) => {3    // 100K comparisons can block tens to hundreds of milliseconds4    const comparison = a[sortKey] > b[sortKey] ? 1 : -15    return direction === "asc" ? comparison : -comparison6  })7}

For large datasets, push the work into a Web Worker:

Show 8 hidden lines9}1011// main.ts12const worker = new Worker("worker.ts")1314function sortAsync(rows: Row[], sortKey: string, direction: SortDirection): Promise<Row[]> {15  return new Promise((resolve) => {16    worker.onmessage = (e) => resolve(e.data)17    worker.postMessage({ rows, sortKey, direction })18  })19}2021sortAsync(largeDataset, "name", "asc").then(setSortedRows)

Server-side sorting is required when the data does not fit in memory. The grid sends sort parameters; the server returns sorted pages.

Frozen Rows and Columns

Pinning is two-dimensional. Pinned (a.k.a. frozen) columns keep identity columns and action columns visible during horizontal scroll; pinned rows keep the header and totals visible during vertical scroll. The fully general layout is a 3 × 3 grid of regions sharing scroll axes:

Implementation requirements:

1. Scroll sync. Centre-row regions share scrollLeft; middle-column regions share scrollTop. The four corner regions are anchored to no scroll axis.
2. Independent virtualization windows. Each scrollable region runs its own visible-range calculator; the centre region runs both row and column virtualization.
3. Shadow indicators. Visual cues (drop shadows or 1 px borders) showing content beneath the pinned regions.
4. Selection continuity. Selection spans all nine regions; range selection has to walk across the seam without losing the anchor cell.
5. Sticky positioning vs separate panes. Modern grids prefer position: sticky cells inside one scroll container (simpler focus model) when the row count fits; large grids fall back to separate panes with synced scroll for performance and overflow control.

Practical defaults:

• Limit left-pinned width to 200-300 px (identity columns).
• Limit right-pinned width to 100-150 px (action buttons).
• Pin at most one or two top rows (header + filter row) and one bottom row (totals).
• Unpin responsively if pinned columns exceed ~60% of grid width.

Row Grouping and Tree Structures

Row grouping turns flat data into a hierarchical view:

1interface GroupedRow {2  type: "group"3  groupKey: string4  groupValue: unknown5  children: (GroupedRow | DataRow)[]6  aggregates: Record<string, number>7  isExpanded: boolean8}910interface DataRow {11  type: "data"12  data: Record<string, unknown>13}1415const grouped: GroupedRow = {16  type: "group",17  groupKey: "department",18  groupValue: "Engineering",19  isExpanded: true,20  aggregates: { salary: 2_500_000, headcount: 50 },21  children: [22    { type: "data", data: { name: "Alice", salary: 150_000 } },23    { type: "data", data: { name: "Bob", salary: 140_000 } },24  ],25}

Client-side grouping works for moderate datasets. Server-side row models (e.g. AG Grid Enterprise) fetch grouped data on demand — expanding a group triggers a request for its children.

Cell Editing

Choose two orthogonal axes: trigger and commit boundary.

The full lifecycle is a small state machine — getting it wrong is how you lose user edits:

Show 5 hidden lines6  isValid: boolean7}89function handleCellEdit(rowId: string, colId: string) {10  setEditState({11    rowId,12    columnId: colId,13    originalValue: getCellValue(rowId, colId),14    currentValue: getCellValue(rowId, colId),15    isValid: true,16  })17}Show 8 hidden lines26function cancelEdit() {27  setEditState(null)28}

Keyboard conventions follow the WAI-ARIA Grid pattern:

• Enter — commit and move to the cell below.
• Tab — commit and move to the next cell.
• Escape — cancel edit, restore original value.
• F2 — enter edit mode on the focused cell.

Accessibility

ARIA Grid Pattern

The WAI-ARIA Authoring Practices define the grid pattern for two-dimensional tabular widgets. Required structure:

1<div role="grid" aria-label="Employee data" aria-rowcount="1000" aria-colcount="10">2  <div role="rowgroup">3    <div role="row" aria-rowindex="1">4      <div role="columnheader" aria-colindex="1" aria-sort="ascending">Name</div>5      <div role="columnheader" aria-colindex="2">Department</div>6    </div>7  </div>8  <div role="rowgroup">9    <div role="row" aria-rowindex="2">10      <div role="gridcell" aria-colindex="1">Alice</div>11      <div role="gridcell" aria-colindex="2">Engineering</div>12    </div>13  </div>14</div>

Critical attributes when virtualizing (Grid and Table Properties):

• aria-rowcount / aria-colcount — total count for the entire dataset, not just rendered rows. Set to -1 if unknown.
• aria-rowindex / aria-colindex — 1-based position within the dataset; must be updated as virtualized rows scroll into view.
• aria-sort — ascending, descending, or none on the active sorted column header.
• aria-selected — for selectable cells or rows.

Keyboard Navigation

The Grid pattern mandates a roving-tabindex strategy: exactly one cell is in the tab sequence; arrow keys move focus inside the grid (WAI-ARIA Grid pattern).

Show 3 hidden lines4      e.preventDefault()5      focusCell(currentRow, Math.min(currentCol + 1, colCount - 1))6      break7    case "ArrowLeft":8      e.preventDefault()9      focusCell(currentRow, Math.max(currentCol - 1, 0))10      break11    case "ArrowDown":12      e.preventDefault()13      focusCell(Math.min(currentRow + 1, rowCount - 1), currentCol)14      break15    case "ArrowUp":16      e.preventDefault()17      focusCell(Math.max(currentRow - 1, 0), currentCol)18      break19    case "Home":20      e.preventDefault()21      if (e.ctrlKey) {22        focusCell(0, 0)23      } else {24        focusCell(currentRow, 0)Show 5 hidden lines

Screen Reader Considerations

Virtualization creates three problems:

1. Rows that do not exist yet. Screen readers cannot read a cell that has not been rendered. Maintain accurate aria-rowcount, and use aria-rowindex so the user knows where they are in the dataset.
2. Focus management on swap. When the row pool recycles, focus must move to the newly rendered cell at the same index, not stay attached to a node that is about to disappear.
3. Live regions for status. Use a polite aria-live region for sort, filter, and pagination announcements.

1<div aria-live="polite" aria-atomic="true" class="sr-only">2  Sorted by Name, ascending. Showing 1 to 50 of 1,000 rows.3</div>

Canvas-based grids are the worst offenders here: by default the canvas is invisible to assistive tech. Google Docs and Sheets work around this by maintaining a parallel DOM mirror that screen readers walk while the canvas renders the visible cells (Google Docs canvas-based rendering).

Performance Optimization

Memoization Strategy

React grids benefit heavily from memoization:

Show 5 hidden lines6    ))}7  </tr>8)910// With memoization: rows only re-render when their data changes11const Row = React.memo(12  ({ data, columns }) => (13    <tr>14      {columns.map((col) => (15        <td key={col.id}>{data[col.field]}</td>16      ))}17    </tr>Show 3 hidden lines

Common memoization defeats:

• New objects in render props (style={{ margin: 10 }}) — reference identity changes each render.
• Inline callbacks (onClick={() => handleClick(id)}) — defeat React.memo.
• Unstable column definitions — define columns outside the component or memoize them.

Batch Updates

Multiple rapid updates should batch into a single render:

1// Without batching: N updates = N renders2updates.forEach((update) => {3  setData((prev) => updateCell(prev, update))4})56// With batching: N updates = 1 render7setData((prev) => {8  let next = prev9  updates.forEach((update) => {10    next = updateCell(next, update)11  })12  return next13})

For real-time data (WebSocket feeds, market data), buffer updates and flush them on requestAnimationFrame. This is the standard rAF-coalescing pattern: callbacks queued during a frame run before the next paint, so flushing once per frame guarantees the work aligns with the display refresh (web.dev: Jank busting).

Show 5 hidden lines6  if (!rafScheduled) {7    rafScheduled = true8    requestAnimationFrame(flushUpdates)9  }10}1112function flushUpdates() {13  rafScheduled = false14  if (updateBuffer.length > 0) {15    setData((prev) => applyUpdates(prev, updateBuffer.splice(0)))16  }17}

Paint Cost: Transform, Containment, content-visibility

Frame cost is dominated by style, layout, and paint — not script. Three CSS-level levers move the needle:

1. Composite-only positioning. Move rows with transform: translate3d(0, ${y}px, 0) (and will-change: transform while a scroll is in flight). The transform stays on the compositor thread; switching to top forces layout for every row that moves (web.dev: Stick to compositor-only properties).
2. CSS containment per row. contain: layout paint on the row element tells the engine the subtree’s layout and paint do not affect the rest of the document, letting it skip large chunks of the render pipeline when a single cell changes (CSS Containment Module Level 2).
3. content-visibility: auto for off-viewport sub-trees. Combined with contain-intrinsic-size, the browser skips style, layout, and paint for elements outside the viewport while keeping them in the accessibility tree and find-in-page index (web.dev: content-visibility, Baseline since 2025).

1.grid-row {2  position: absolute;3  inset-inline: 0;4  height: var(--row-h, 32px);5  transform: translate3d(0, var(--row-y), 0);6  contain: layout paint;7  content-visibility: auto;8  contain-intrinsic-size: auto var(--row-h, 32px);9}

Memory Management

Large grids consume memory in multiple ways:

For grids with 100K+ rows:

• Push filtering and sorting to the server — do not load all rows.
• Fetch rows lazily as they enter the viewport (cursor-based pagination).
• Treat the client cache as a sliding window, not an indefinite store.

Clipboard, Copy, and Paste

Excel-style copy/paste inside a custom widget means intercepting the native copy, cut, and paste events while the grid owns focus. The grid serializes its current selection (or active cell) into the clipboard payload and parses incoming text — typically TSV — back into a transactional update.

AG Grid documents this surface explicitly: processCellForClipboard and processDataFromClipboard hook the serialization and the inverse parse, while cellSelection enables the Excel-compatible TSV copy of a range (AG Grid Clipboard). Canvas grids have no native clipboard at all and have to mint a hidden <textarea> to receive paste events on each focus change (Google Workspace Updates: Canvas-based rendering).

Undo and Redo

Inline editing without undo is a footgun. The minimum viable model is two stacks of commands, not snapshots:

1type EditCommand = {2  apply: () => void3  invert: () => void4  label: string5}67const undo: EditCommand[] = []8const redo: EditCommand[] = []910function dispatch(cmd: EditCommand) {11  cmd.apply()12  undo.push(cmd)13  redo.length = 014}1516function undoOnce() {17  const cmd = undo.pop()18  if (!cmd) return19  cmd.invert()20  redo.push(cmd)21}

Operational rules learned the hard way:

• Cap depth. Production grids cap the stack at 10–50 entries to bound memory; AG Grid defaults undoRedoCellEditingLimit to 10 (AG Grid Undo / Redo Edits).
• Clear on order changes. Sort, filter, group, and column-reorder operations invalidate row indices and must clear both stacks (or remap them) — AG Grid clears them.
• Coalesce paste batches. A single paste of N cells should be one undo entry, not N. Use a transaction wrapper that records one composite command.
• Server-side editing. When mutations go through cellEditRequest (read-only data), the grid is not the source of truth — the server is. Local undo must trigger a compensating server call, not just flip a local cache.
• Ctrl+Z bindings only inside the grid. Capture undo/redo only while focus is inside the grid; release to the browser otherwise so users do not lose form text outside the grid.

Real-World Implementations

Google Docs and Sheets: Canvas-First Architecture

Google Docs migrated its document rendering from DOM to canvas in 2021 to improve performance and produce a consistent appearance across platforms (Workspace Updates). Google Sheets has used canvas-style rendering for the main cell area since well before that.

Canvas rendering enables:

• Hundreds of thousands of visible cells without DOM node-count cost.
• Consistent cell formatting across browsers (borders, conditional formatting, custom selection rendering).
• Single-draw paint per frame instead of per-cell layout.

The trade-offs are real and visible:

• Find-in-page (Ctrl+F) opens a custom dialog because native browser search does not see canvas content.
• Copy/paste must intercept clipboard events and serialize from the data model.
• Accessibility relies on a parallel DOM mirror — Google’s announcement explicitly notes that assistive-technology support is preserved through that mechanism.

Notion: Block-Based Rows

Notion’s database views are built on top of its block model — every database row is a page block whose properties are themselves blocks (Notion data model). A 20,000-row database can therefore translate into hundreds of thousands of blocks, with real-time collaboration synchronizing block changes via WebSocket and a client-side RecordCache (IndexedDB) holding the working set.

The performance pressure points are:

• Formulas and rollups recalculate per view.
• More visible properties per row inflate the per-row payload.
• Inline databases on busy pages compound loading work.

Notion mitigates this with progressive loading — visible rows hydrate first, off-screen rows hydrate as the user scrolls.

AG Grid in Financial Applications

Trading desks use AG Grid for real-time market data because the row models map cleanly onto the problem:

• The Viewport row model lets the server know exactly which rows are visible, so it can stream updates only to those rows.
• Custom cell renderers handle conditional formatting (red/green ticks).
• Hundreds of price updates per second batch into single-frame DOM updates via the rAF-coalescing pattern.

The architecture handles 50+ columns of continuous updates because only visible cells receive DOM updates and aggregation lives on the server.

Conclusion

Data grid architecture choices cascade through the rest of the system. Headless vs full-featured vs canvas vs React-integrated determines bundle size, feature velocity, performance ceiling, and accessibility cost.

Key takeaways:

1. Virtualize both axes past a few hundred rows. Lighthouse already complains at ~1,400 body nodes; a wide grid hits that on the first thousand rows. Use transform: translate3d, contain: layout paint, and content-visibility: auto to cap paint cost.
2. Match row model to scale and delivery mode. Pagination, infinite scroll, and streaming each have a different backpressure story; client-side fits up to ~100K rows, beyond that you need infinite, server-side, or viewport models.
3. Pinning is two-dimensional. Frozen rows + frozen columns produce a nine-region layout; selection, focus, and keyboard navigation must coordinate across all of them.
4. Editing is a state machine. Cell vs row vs full-form commit modes change when the boundary fires, not the lifecycle. Always design for cancel, validation failure, and server reject.
5. Accessibility is explicit work. Virtualization breaks default screen-reader behaviour; budget time for ARIA roles, roving tabindex, F2 edit-mode toggle, and aria-rowindex updates.
6. Clipboard and undo are first-class features. Excel-style copy/paste and bounded undo/redo are not add-ons; they are how power users trust the grid.
7. Canvas is a last resort. The throughput is real; so are the accessibility, find-in-page, copy/paste, and IME costs.

The best data grid is the one that solves your users’ problems without becoming a maintenance burden. Start with the simplest architecture that meets requirements; reach for canvas only when measurement, not intuition, says you must.

Appendix

Prerequisites

• DOM and browser-rendering fundamentals.
• React hooks and component lifecycle (for the React-based examples).
• Time-complexity basics (O(1), O(log n), O(n)).
• Familiarity with ARIA and keyboard accessibility patterns.

Terminology

• Virtualization / windowing — rendering only visible items plus a buffer; recycling DOM nodes as the user scrolls.
• Overscan — extra items rendered beyond the visible region to mask flashes during fast scroll.
• Row model — the data-loading strategy: client-side loads everything, server-side / infinite / viewport models load on demand.
• Pinning / freezing — keeping columns or rows visible regardless of scroll position.
• Headless UI — a library that ships logic without rendering opinions; you supply the markup.

Summary

• Data grids must virtualize past a few hundred rows to maintain performance — browsers struggle past ~1,400 body DOM nodes.
• Four architectures dominate: headless (TanStack Table — control), full-featured (AG Grid — batteries included), canvas-based (Google Sheets / Docs — throughput), React-integrated (MUI X — balance).
• Row models range from client-side (everything in memory) to server-side (fetch on demand) — pick by dataset size and update profile.
• Column pinning produces three vertically-synced scroll regions and must coordinate selection, focus, and keyboard navigation across them.
• Accessibility requires explicit ARIA roles, roving-tabindex keyboard handlers, and aria-rowindex updates as virtualized rows scroll in.
• Profile before optimizing: memoization, rAF-batching, and Web Workers each target a different bottleneck.

References

• WAI-ARIA Grid Pattern — definitive accessibility specification for data grids.
• WAI-ARIA Grid and Table Properties — aria-rowcount, aria-rowindex, virtualization rules.
• TanStack Table v8 — Migrating to v8 — headless rewrite rationale and API.
• TanStack Virtual — Virtualizer API — measureElement, ResizeObserver-driven dynamic sizing, transform positioning.
• AG Grid Row Models — client-side, infinite, server-side, and viewport row models.
• AG Grid Clipboard — processCellForClipboard, processDataFromClipboard, range copy.
• AG Grid Undo / Redo Edits — undoRedoCellEditing, stack-clear semantics on sort/filter.
• AG Grid Bundle Size guidance — module-based imports for production bundles.
• MUI X DataGrid Virtualization — rowBufferPx, columnBufferPx, Community-tier 100-row cap.
• react-window — lightweight virtualization library by Brian Vaughn.
• web.dev: Virtualize Long Lists — Google’s guide to windowing with react-window.
• web.dev: content-visibility — skip rendering work for off-screen sub-trees.
• web.dev: Stick to compositor-only properties — why transform beats top for moving rows.
• W3C CSS Containment Module Level 2 — contain property semantics; baseline for content-visibility.
• W3C CSS Containment Module Level 3 — placeholder for ongoing containment work.
• web.dev: DOM size and interactivity — how DOM size impacts INP.
• Chrome Lighthouse: Avoid an Excessive DOM Size — concrete thresholds (800/1,400 nodes).
• web.dev: RAIL — frame budget and perceived-latency targets.
• web.dev: Jank busting for better rendering performance — requestAnimationFrame and rendering pipeline.
• MDN: Clipboard API — async clipboard reads/writes, permissions model.
• Google Workspace Updates: Canvas-based rendering for Docs — official announcement of the DOM → canvas migration.
• Notion data model — block-based architecture behind Notion’s database views.
• MDN: ARIA grid role — role reference.