How to choose a React data grid

Every data grid's feature list contains sorting, filtering, grouping, virtual scrolling and Excel export. So the comparison table you build in week one will be a wall of green ticks, and it will not help you choose.

What separates these libraries only shows up later: at a million rows, on the day the licence expires, the first time a designer asks for a different row height, or when the component you picked has to run inside a locked-down enterprise CSP.

Here are the questions worth asking instead. We build one of these things, so treat this as an informed opinion rather than a neutral survey — but every check below is one you can run yourself, on any candidate, without taking our word for it.

1. What happens at the bottom of your largest dataset?

Load the biggest table you will realistically have, scroll all the way down, and count the last rows.

This sounds trivial. It is the single most reliable way to find a broken virtual scroller, because browsers silently cap how tall an element may be — around 33.5 million device pixels in Chromium, about half that in Firefox. A grid that maps rows to pixels one-to-one runs out of scrollbar before it runs out of rows, and the last few become unreachable.

Do it again at 125% display scaling. The cap is in device pixels, so a bug that hides at 100% appears there.

2. How many DOM nodes does it actually keep?

Open dev tools, count the rendered rows. A grid claiming virtualisation should hold a couple of dozen regardless of dataset size. Some hold hundreds, which is fine at 10,000 rows and miserable at a million.

While you are there, type into a filter with the full dataset loaded and watch for dropped frames. Virtualisation bounds rendering work; it does nothing about a synchronous pass over every row, which is where large-dataset latency usually lives.

3. What does installing the worker involve?

If the grid moves work off the main thread — and at scale it should — find out what that costs you at install time. Some ask you to copy a file into public/, some need a bundler-specific import, some need different setup per framework.

That step is not just an inconvenience: it is a thing that breaks on upgrade, differs between your dev and prod builds, and confuses every new person on the team. Ask whether it works with no configuration at all, and if not, what the instructions look like for your bundler specifically.

4. Does licence verification happen offline?

For commercial grids, this is the question with the longest tail. A licence check that calls the vendor's server makes your production application depend on that vendor's uptime — forever, on every page load, including during your customers' incidents.

Offline verification (a signed key checked locally against a public key baked into the package) has none of that. Ask explicitly; "licence key" does not tell you which model you are getting.

5. What happens when the licence is invalid?

Ask what a user sees when the key is missing, expired or wrong. There are two answers, and the difference matters more than any feature.

Soft failure: the grid renders, works, and shows a watermark. A renewal that lands in a spam folder costs you a mark on a screen.

Hard failure: the component throws. Now your application's availability is coupled to your billing status, and a lapsed invoice takes down a production dashboard.

Get this in writing before you buy.

6. Is the API you would write actually documented?

Feature lists say "editing". They rarely say whether you can start editing from code, whether validation runs in the engine or only in the UI, whether undo has a public API, or which events fire in what order.

Pick one workflow you know you need — say "user edits a cell, we validate against the server, then we undo" — and try to write it from the documentation alone, without support. If you cannot, that is your integration timeline talking.

7. How is styling done?

Ask whether themes are CSS custom properties or a compiled stylesheet you fork. The first survives your design system changing its mind; the second becomes a maintained patch.

Two specifics worth testing: change the row height and see whether anything misaligns, and open a popup (filter, column chooser) to check it inherits the theme — popups are usually portalled out of the grid's DOM and are where theming most often leaks.

8. Can it run under your CSP?

If you are shipping into a bank, a hospital or anything with a security review, find your Content-Security-Policy first and check what the grid needs. Blob workers need worker-src blob:. Inline styles need style-src 'unsafe-inline' or nonces. Runtime eval for formula parsing is a hard no in most such environments.

Finding this out during the security review is the most expensive possible time to find it out.

---

A short honest note about us

We answer these the way we do because we hit each one the hard way. Our own grid failed question 1 three times before the fix stuck. Our workers are embedded so question 3 has no answer at all. Verification is offline and failure is soft, deliberately.

Where we are weaker: we are a small team with a much shorter track record than the established options, and our ecosystem — third-party examples, Stack Overflow answers, people who already know the API — is correspondingly thin. That is a real cost and you should weigh it.

The good news is that none of the eight questions require trusting anyone. Every one of them is answerable in an afternoon with a real dataset and dev tools open.

You can run all of them against ours: the playground has every feature on its own page, and the performance demo goes to two million rows in the browser.