Comcast/react-data-grid: a virtualized React grid still shipping as 7.0.0-beta

What react-data-grid solves, and who it is actually for

Rendering a table of 50,000 rows in React by mapping over an array produces 50,000 DOM nodes and a frozen tab. react-data-grid exists to avoid that. The README states the component is "designed to handle large datasets efficiently" and that virtualization means "columns and rows outside the viewport are not rendered." That single sentence is the whole pitch. Everything else in the feature list, from frozen columns to cell copy and paste, is a convenience layered on top of the same rendering model.

The intended user is a React application developer who already has rows in memory or can page them in, and who needs an editable, sortable, keyboard-accessible grid without pulling in a charting suite or a server-side data layer. The README lists React 19.2+ support, server-side rendering, tree-shaking with no external dependencies, and TypeScript types. That combination points at product teams building internal tools, admin panels and data editors where the grid is one screen among many and bundle size matters.

It is a poor fit for anyone who wants a grid to fetch, cache, group and paginate data on its own. The README describes props and renderers; it does not describe a data source abstraction. You bring the rows.

How the virtualization and column model fit together

The public surface is two props: columns and rows. A Column is keyed by a string, carries a name for the header, and is typed against the row interface, so a typo in a key is a compile error rather than a blank cell. The README's basic example declares columns as a readonly array of Column<Row> and passes both arrays straight to DataGrid.

Virtualization is driven from the same place. Because the grid knows the viewport height and the row height, it can compute which rows intersect the visible area and render only those. Row height is not fixed by default: the README documents a rowHeight prop that "supports both fixed heights and dynamic heights per row," plus headerRowHeight and summaryRowHeight. Dynamic heights are the harder path, since the grid has to measure rows it has not rendered yet, and the README points to a dedicated VariableRowHeight example rather than explaining the measurement strategy in prose.

Column behaviour is layered on the same column array. Sorting is multi-column: clicking a sortable header toggles ascending and descending, and Ctrl+Click or Meta+Click adds another column to the sort. Frozen columns stay visible during horizontal scrolling. Column spanning, column grouping and row grouping are separate examples on the site. Row selection, summary rows, cell editing, copy and paste, and drag-to-fill are all listed as features, each with its own example page. The uniform pattern is that the grid owns rendering and interaction, and you own state and data.

Installing react-data-grid and rendering a first grid

The README gives four package manager commands and they are interchangeable. Pick the one your project already uses. The npm form is the shortest:

npm i react-data-grid

The package is published as ECMAScript modules. The package.json confirms this with "type": "module" and a single export map that points both import and default at ./lib/index.js, with types at ./lib/index.d.ts. There is no CommonJS build, so a project still compiling to require() will not resolve it.

Styles are a separate import. The package exposes ./lib/styles.css in its exports map, and the README says to import it in your application:

import 'react-data-grid/lib/styles.css';

With styles in place, the README's getting-started example is a complete working grid. Define a row interface, declare columns against it, and pass both to the component:

import 'react-data-grid/lib/styles.css';

import { DataGrid, type Column } from 'react-data-grid';

interface Row {
  id: number;
  title: string;
}

const columns: readonly Column<Row>[] = [
  { key: 'id', name: 'ID' },
  { key: 'title', name: 'Title' }
];

const rows: readonly Row[] = [
  { id: 0, title: 'Example' },
  { id: 1, title: 'Demo' }
];

function App() {
  return <DataGrid columns={columns} rows={rows} />;
}

You should see a two-column grid with an ID header and a Title header, two rows of data, and the default light or dark styling depending on the user's system preference. If the grid renders without borders or hover states, the stylesheet import is missing or was dropped by the bundler.

The README also flags one bundler trap. Vite 8+ minifies CSS with lightningcss by default, and the README says that minifier has a bug with light-dark() syntax. The documented workaround is to change the build config:

build: {
  cssMinify: 'esbuild',
  // or
  cssTarget: 'esnext'
}

That is a real constraint, not a footnote: the built-in theming depends on light-dark(), so a minifier that mangles it breaks the default appearance.

The 7.0.0 beta line is the adoption decision

The repository's package.json declares version 7.0.0-beta.60, and the releases list shows v7.0.0-beta.61 from 2026-07-14, v7.0.0-beta.60 from 2026-07-09, and v7.0.0-beta.59 from 2025-12-04. The README never mentions a beta status. A reader who follows the install command and the getting-started example would not learn from the README that they are installing a pre-release.

That gap matters. Beta releases can change prop names, renderer signatures and CSS variables between versions, and the CHANGELOG is where those changes are recorded. The README documents the current API, not the API you will get if you pin an older beta. A team that installs react-data-grid, builds against it, and then upgrades without reading the changelog is exposed to breaking changes that the README will not warn about.

The last push to the repository was on 2026-09-18, so work is ongoing. The repository is not archived. But an active repository and a stable release line are different things, and the releases list is the evidence for the second one. Treat the version you install as a deliberate choice, pin it in package.json, and read the changelog before moving.

There is a second, quieter constraint. The README's feature list is long, and most entries link to a separate example page rather than to API documentation. That is fine for discovery but thin for implementation: if you need to know the exact shape a custom renderer receives, the README will send you to the website source rather than tell you.

Theming, CSS variables and what the styling layer assumes

The grid ships light and dark themes through the CSS light-dark() function, with the README stating that the theme follows the system preference when color-scheme: light dark; is set. To force one theme, the README recommends setting color-scheme on :root, or applying the rdg-light or rdg-dark class to an individual grid. The second option is the useful one when a single page needs a grid in a fixed theme regardless of the operating system setting.

Beyond the two themes, customization runs through CSS variables on the .rdg class. The README lists variables for selection width and colour, font size, text and background colours, header background and draggable header background, row hover and selected backgrounds, border width and colour, summary border width, and checkbox focus colour. The colour variables are written as light-dark() pairs, so overriding one means supplying both values or losing automatic switching for that variable.

You can also target a single grid by class. The README shows a custom class setting --rdg-background-color, --rdg-selection-color and --rdg-font-size, then passing that class to DataGrid alongside className and style props. The style prop carries width and height, which the README's example sets to 800 and 600.

One thing the README does not address is a non-CSS-in-JS path for consumers who cannot import a stylesheet. The exports map contains only lib/styles.css, so the styling layer is not exposed as a JS module. If your build pipeline cannot process a CSS import from a dependency, the grid will render unstyled and the README offers no alternative.

Where react-data-grid is the wrong choice, and what to compare it with

The clearest wrong-tool case is a grid that must own the data lifecycle. react-data-grid takes rows as a prop. It does not fetch, cache, paginate or invalidate them, and the README does not present a data source interface. If your requirement is "give the grid a URL and let it page," you are building that layer yourself, and the grid is only the rendering half of the problem.

A second case is a team that cannot accept a pre-release dependency. The published version is 7.0.0-beta.60. If your release process forbids beta versions in production dependencies, the current line does not qualify, and the README gives no stable version to fall back to.

The obvious alternative is AG Grid, which appears in the related searches as a direct comparison. The difference in approach is structural rather than cosmetic. AG Grid ships a client-side row model plus server-side row models, so paging, grouping and filtering can be delegated to the grid. react-data-grid stays at the component level: you pass rows, you handle the rest. That makes react-data-grid smaller and easier to reason about when your data is already in memory, and it makes AG Grid the better fit when you want the grid to manage fetching and aggregation. The trade is control against built-in scope.

There is also a naming trap worth knowing before you search for help. The related searches include "react data grid adazzle" and "react data grid (adazzle)" alongside "react data grid comcast." Two different projects share the react-data-grid name. If you land on documentation that does not match the props you are using, check which package you actually installed.

Licence and maintenance cost

The repository's package.json declares "license": "MIT", and the repository root contains a LICENSE file. The metadata supplied for the repository lists the licence as NOASSERTION, which is the classifier failing to match the file rather than a different licence. Anyone depending on this package should read the LICENSE file directly rather than rely on either label; this is a description of what the files say, not legal advice.

MIT is permissive, so the practical implication is that you can ship the grid inside a commercial product without a separate agreement. The README does not mention a commercial edition, a paid tier or a licence key, and the related searches include "is react data grid free," which the licence declaration answers.

Upgrade cost is the more concrete concern. The package is on a beta line, so upgrades should be deliberate: pin the exact version, read CHANGELOG.md before bumping, and re-run your own grid tests. The repository's own test setup uses vitest with separate browser, node and visual projects, and the package.json exposes test:ci and test:ci:update scripts. That visual test project exists because rendering changes are the kind of change a unit test will not catch, which is a reasonable signal about where breakage tends to appear in a grid. Your own upgrade checklist should include a visual check of frozen columns, row heights and theme switching, since those are the areas where the README documents the most configuration.

Editorial conclusion

Adopt react-data-grid if you need a virtualized, typed grid inside a React 19.2+ app and can pin a beta version deliberately. Do not adopt it if you need a stable release line, a built-in data source, or a grid whose API you will not have to revisit at 7.0.0 final. Before installing, check the published version tag rather than the README, and confirm your bundler handles the light-dark() CSS the way the README describes.

Frequently asked questions

Official sources

1. Comcast/react-data-grid on GitHub
2. Issues
3. Project website
4. README
5. Releases