react-virtualized-auto-sizer measures a parent element and hands the size to a child

The missing pixel measurement in a virtualised list

react-virtualized-auto-sizer measures the available width and height of an HTMLElement and passes those values as props to a child component. That is the whole idea, and it exists because a virtualised list or grid cannot lay out rows without knowing how much space it has.

Think about what a windowed list actually needs. It renders a handful of rows out of a much larger collection, and it has to know the height of the scroll viewport to decide which rows are visible and how far the scrollbar should stretch. The container is sized by CSS, by flexbox, by a grid, by a sidebar that can be collapsed, and sometimes by a user dragging a divider. None of that is knowable at build time, and hard-coding a pixel height is the thing that breaks the moment the layout changes.

So the component measures and passes the numbers down. The documentation describes it as measuring the available width and height of its parent HTMLElement and passing those values as width and height props to its children.

The package is written in TypeScript, published under the MIT licence, and the current version is 2.0.4. The documentation site is at react-virtualized-auto-sizer.vercel.app, and the repository is maintained by Brian Vaughn, who is also the author of react-virtualized.

The audience is developers building a virtualised list, grid, table or spreadsheet layout in React, and specifically those whose windowing library does not measure its own container.

A fork of a fork, and a note about newer react-window

The history of the package explains both what it does and whether you need it.

The documentation states that this package began as a fork of the AutoSizer component from react-virtualized, and that it was intended for use with earlier versions of react-window. The AutoSizer component itself began as a fork of the javascript-detect-element-resize package, which is where the technique of injecting a script to detect element resize came from.

Then there is the note that decides the question for most new projects. More recent versions of react-window use ResizeObserver natively and do not require this package.

That is the honest positioning. The library was carved out of react-virtualized so that windowing users could depend on the measurement component alone, then split away again when react-window absorbed the capability. If your project is on a current react-window, adding this dependency duplicates work the library already does.

The same logic applies in reverse to react-virtualized. If you already depend on react-virtualized for its grid or list, the AutoSizer component is already inside that package and this standalone copy buys you nothing except a smaller import graph.

The case that remains is a project on an older react-window that needs measurement, or an application that uses neither react-window nor react-virtualized and wants a well-worn measurement component instead of writing a ResizeObserver hook by hand.

ResizeObserver does the measuring, with a box option for CSS quirks

The mechanism is the browser's own ResizeObserver, which reports changes to an element's box size as they happen rather than waiting for a window resize event.

The optional box prop maps directly onto the ResizeObserver box parameter and decides which box model is observed. With border-box, the observed size is the border area as defined in CSS. With content-box, it is the content area. With device-pixel-content-box, it is the content area measured in device pixels, before any CSS transforms are applied to the element or its ancestors.

That third option is the one to know about. A transformed ancestor, a zoom setting or a scaled container changes the mapping between CSS pixels and physical pixels, and content-box measured in device pixels is the way to get a number that reflects what is actually on the screen.

There is also a nonce prop, which exists for a specific problem. In environments that do not support the ResizeObserver API, the component falls back to injecting an inline StyleSheet, and a Content Security Policy without unsafe-inline will block it. Passing a nonce lets that inline style be permitted. If your application runs under a strict CSP, this is the prop that stops the measurement from failing silently.

The remaining props are ordinary DOM plumbing: className, style and id for the auto-sizer element, data-testid for test frameworks such as Testing Library, tagName to change the root element from its default of div, and an onResize callback that fires after a resize with the new width and height.

renderProp versus ChildComponent, and the undefined first render

There are three ways to receive the measured size, and the documentation is opinionated about which to use.

The Child prop, which passes a child component the width and height, is marked as deprecated in favour of ChildComponent or renderProp. ChildComponent takes a component that receives width and height as props, and renderProp takes a function that is called with the same values.

The guidance is specific: use renderProp if you need access to local state, and use ChildComponent instead for better memoization if you do not. That difference is the practical reason the two exist. A component reference can be memoized and skipped when the parent re-renders, whereas an inline function prop is a new reference on every render and defeats the memoization of whatever you pass to it.

The same props carry a warning that is the most likely thing to bite a first-time user. Width and height are undefined during the initial render, including during server rendering. A child that immediately uses the width to lay out items will therefore see undefined on the first pass, and any code that multiplies by the width will produce NaN.

The practical consequence is that the first render has to be handled explicitly, either by rendering nothing until a size arrives or by guarding the calculation. The same rule applies to server rendering, where no measurement has happened at all, so a component that assumes a number will fail during SSR.

Installing the package and wiring it to a child

Installation is one npm command:

npm install --save react-virtualized-auto-sizer

The component has no required props, so a minimal usage passes the control and a child component. The documented shape of the API, taken from the props table, is short:

- The component measures the available width and height of its parent HTMLElement and passes those values as width and height props to its children. - The ChildComponent prop is the child component to be passed the available width and height values as props, and the renderProp prop is the render prop to be passed the same values. - Use renderProp if you need access to local state, and use ChildComponent instead for better memoization if you do not.

Two things follow from that list for a first run. Because width and height start out undefined, the child should tolerate an undefined value or the parent should not render the child until the first measurement lands. And because the component measures its parent, the parent element needs a definite size for the measurement to be meaningful.

The documentation site hosts the usage examples under examples/basic-usage, and a separate common questions page collects the frequently asked questions that the README points at rather than repeating.

One package built with vite, docs and library from the same source

The repository is a modern JavaScript package layout, and the package metadata shows how the artefact is built.

The published entry points are a CommonJS build at dist/react-virtualized-auto-sizer.cjs, an ES module build at dist/react-virtualized-auto-sizer.js, and type declarations at dist/react-virtualized-auto-sizer.d.ts. Only the dist directory is published.

The build itself runs on vite with two targets. The build script calls build:lib and then build:docs, and each of those runs a vite build with a TARGET environment variable set to lib or docs, so the library bundle and the documentation site are produced from the same repository by the same tool. There is a separate preview script and a dev script for local work.

The toolchain around that is worth naming because it says what kind of project this is. The repository is a pnpm workspace, with an integrations directory containing a vite project used for end-to-end tests, and the e2e scripts install Playwright with its dependencies and run the suite there. Unit tests are configured through vitest.config.ts with a setup file. Linting is eslint and formatting is prettier, both with a check mode for CI. The scripts directory holds tsx-based compile steps for the documentation, the examples and the search index, and there is a compress:og-image script for the social image used in the README.

The licence is MIT, with the terms in a LICENSE.md file, and the project keeps a CHANGELOG.md alongside it.

Frequent releases for a package with a small surface

The release history is short and recent: version 2.0.4 was published on 2026-10-16, 2.0.3 on 2026-02-13 and 2.0.2 on 2026-01-05. The last push to the main branch was on 2026-10-19, three days after the newest tag, so the working tree is slightly ahead of the published package.

For a component with this little code in it, that cadence is what you would expect. There is not much that can break in a box measurement, so the releases are mostly small adjustments rather than features, and the changelog is the place to look when you want to know what changed between the version your lockfile has and the current one.

The one thing to weigh is the dependency question from earlier, because it determines whether you need this package at all. If you are on a current react-window, the native ResizeObserver support there removes the reason to install it. If you are on an older react-window, or you are building a windowed layout without either library, this is a maintained, MIT licensed component with a documented API and a live documentation site, and it fills the gap.

There is also the option of writing the measurement yourself. A ResizeObserver hook of your own is a page of code, and it gives you exactly the shape of API your application wants. The argument for the package is not that the code is impossible to write, it is that this one is written, documented and already handles the box model option, the CSP nonce fallback and the memoisation differences between the two child props.

Editorial conclusion

react-virtualized-auto-sizer is the right choice when you are on a react-window version without native ResizeObserver support and need the measured pixel size of a container, and it is the wrong choice for a new react-window project, because recent versions observe resizes natively and the package documentation says so itself. Before adding the dependency, check whether your react-window version already handles container size, and if you do adopt it, guard your render for the undefined width and height on the first pass, including during server rendering.

Frequently asked questions

Official sources

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