react-virtualized: React components for lists and tables that outgrow the page

The problem it addresses: a list that is larger than the viewport

The package describes itself as React components for efficiently rendering large lists and tabular data, and the package metadata repeats the idea more specifically, calling them components for large, scrollable lists and tabular data.

The problem is familiar to anyone who has built a data grid. A table with a few hundred rows is fine, because the browser can lay them all out. A table with a few hundred thousand rows is not, because each row is a React element with its own reconciliation cost, and the browser spends its time on nodes nobody is looking at. The usual fix is windowing: render only the rows that are visible plus a small margin, and reuse those DOM nodes as the user scrolls.

The repository topics name the two relevant ideas, virtualization and windowing, along with grid, list, listview and tabular-data, so the scope is clear. This is not a data fetching library and it is not a table with sorting and filtering built in. It is the layer that decides which slice of your data is currently in the DOM.

The audience is a React developer with a list or grid whose size is driven by the user, usually a log tail, a file browser, a large catalogue or an analytics table. The value proposition is that the components already know how to size themselves, keep the scrollbar honest and avoid rendering what is off screen.

What the package actually contains, read from its metadata

The project README is mostly a sponsor list, so the package metadata is the more informative document. The keyword list in package.json is worth reading as a description of the component surface:

    "react",
    "reactjs",
    "react-component",
    "virtual",
    "list",
    "scrolling",
    "infinite",
    "virtualized",
    "table",
    "fixed",
    "header",
    "flex",
    "flexbox",
    "grid",
    "spreadsheet"

Taken together with the repository topics, that points at a list component, a grid component and a table component, with support for fixed rows and headers, scrolling, infinite data and a flexbox layout mode. The spreadsheet keyword is the one to watch, because a spreadsheet-shaped grid and a plain list have very different requirements around column sizing and cell rendering.

The version in package.json is 10.0.0, and the module is declared as an ES module with type set to module. The published entry points are split three ways:

  "main": "dist/react-virtualized.cjs",
  "module": "dist/react-virtualized.js",
  "types": "dist/react-virtualized.d.ts",

and the exports map adds a styles entry point alongside the package metadata, which tells you the stylesheet is shipped as a separate importable file rather than being injected by a JavaScript side effect at runtime.

The build: Vite targets, a pnpm workspace and a separate stylesheet

The v10 tree is a modern toolchain, and the scripts in package.json show how it is put together. The top level build is a fan out over the build scripts:

    "build": "pnpm run /^build:.*/",

and the two build targets are driven by an environment variable that selects the target, with Vite doing the compiling:

    "build:docs": "cross-env TARGET=docs vite build",
    "build:lib": "cross-env TARGET=lib vite build",

That split is the interesting part. The same Vite configuration produces two different outputs, one for the documentation site and one for the library bundle, so the docs examples and the shipped code are built from the same sources rather than maintained separately.

The package manager is pnpm, and the repository carries pnpm-lock.yaml and pnpm-workspace.yaml, so the docs, the library and the integration examples live in one workspace.

The published artefact is small by design. The files array contains only dist, and the exports map exposes the CommonJS build, the ES module build, the type declarations and the stylesheet:

  "exports": {
    ".": {
      "types": "./dist/react-virtualized.d.ts",
      "import": "./dist/react-virtualized.js",
      "require": "./dist/react-virtualized.cjs"
    },
    "./styles.css": "./dist/styles.css",
    "./package.json": "./package.json"
  },

One detail worth knowing before you bundle: the package declares sideEffects for its CSS files, which is the flag that tells a bundler not to drop the stylesheet import when it looks unused.

The v10 rewrite and the codemods that come with it

The published releases tell an uneven story. There is 9.22.6 from 2025-01-20, v9.22.4 from 2023-04-09 and v9.22.3 from 2020-12-18. So the last tag on the 9.x line is more than a year older than the 10.0.0 version written into package.json, and the repository itself was pushed to on 2026-10-19.

That gap is the central fact for anyone deciding what to install. A team that upgrades today is either staying on the 9.x line or pinning a pre-release or a git dependency, and the CHANGELOG.md at the repository root is the place to read what actually changed between them.

The repository has a codemods/ directory, which is the clearest sign that the v10 release is a breaking change with a supported migration path. Codemods exist to rewrite your call sites automatically, and the presence of a directory for them usually means the API changed in ways that a find and replace cannot handle. Using them is also the safest route: a manual migration across a component set this wide is where mistakes get made.

The rest of the tree reinforces that this is a working project rather than a stalled one. There is a CHANGELOG.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, an eslint.config.js, a prettier.config.js, a postcss.config.js, a tsconfig.json, a .prettierignore, and a public/ directory for the static assets the documentation site serves.

How the documentation and the examples are produced

The documentation is a Vite application rather than a set of markdown files, and the scripts show the pipeline. A dev server is one command:

    "dev": "vite"

and the compile step is a fan out over separate tasks, each run with tsx:

    "compile": "pnpm run --sequential /^compile:.*/",
    "compile:docs": "tsx ./scripts/compile-docs",
    "compile:examples": "tsx ./scripts/compile-examples",
    "compile:search-index": "tsx ./scripts/compile-search-index",

So the documentation, the examples and a search index are generated separately and in sequence, and there is a further task for compressing the social preview image. The search index matters more than it looks: a component library with dozens of props is only usable if you can find the prop you need, and generating that index from the source means it does not drift out of date.

The docs are deployed separately from the library, and the repository shows both: a vercel.json for the documentation deployment and a vite.config.ts for the build. The live site is at react-virtualized-docs.vercel.app, and the project points readers there for live examples rather than describing the components in prose. There is also an integrations/ directory, which is where framework specific examples are likely to live, and an index.tsx at the root that is probably the development entry point for the docs app.

Testing runs on Vitest, with vitest.config.ts and vitest.setup.ts, so the components are exercised in a DOM environment rather than only through the documentation site.

Licence, sponsorship and the limits of a single-maintainer library

The licence is MIT, and it is stated in both the package metadata and the LICENSE file, so a commercial product can use the components without any copyleft obligation to publish changes.

The governance picture is worth reading carefully. The README is largely a sponsor page: individual sponsors through GitHub Sponsors and a coffee link, company sponsors including Treasure Data and HPE Dev, and a long OpenCollective list. A project funded that way is not a business with a support contract, and the sponsorship is what keeps the maintenance time coming. The point is not negative, it is about what a reader can expect: a well used component set maintained by one person with sponsorship behind it, rather than a team with a roadmap.

That has a practical consequence for adoption. The v9 to v10 gap is visible in the release dates, and the fact that the 10.0.0 version sits in the tree while the published line stops at 9.22.6 means the migration is still in progress. A team that needs a stable, pinned dependency today is choosing the 9.x line, and a team that wants the v10 API is choosing to track a moving target.

There is a second limit worth naming. The project README does not describe the component API at all, so the documentation site is the only real reference, and it is a separately deployed application. If you are evaluating the library offline, the published releases and the CHANGELOG.md are the whole of what you can read here, and the props documentation lives one click away.

Editorial conclusion

Use react-virtualized when you have a list or grid that is large enough that the browser cannot render every row, and you want the windowing handled for you rather than written by hand. Do not start a new v10 migration on the assumption that a v10 package is published, because the listed releases stop at 9.22.6, and do not adopt it if your rows change height dynamically and you need that handled for you, since the documentation does not describe a measured-row mode. Before you commit, check the CHANGELOG.md in the repository against the version on npm, and run the codemods in the codemods/ directory rather than editing call sites by hand.

Frequently asked questions

Official sources

1. bvaughn/react-virtualized on GitHub
2. License: MIT
3. Project website
4. README
5. Releases