You are virtualizing a React chat log where each message's height depends on its content, so offsets cannot be computed from a single row height. How do virtualizers handle unknown row heights, and what goes wrong while the measurements settle?

## Why fixed-height math stops working Uniform rows give you a closed form: index from `scrollTop / rowHeight`, offset from `index * rowHeight`, total from `count * rowHeight`. All three are O(1) and touch no DOM. Variable heights destroy every one of them. You cannot know a message's height until it has been laid out with its real text, at the real container width, in the real font. So the virtualizer maintains state it did not previously need: - a **height cache**, one entry per item, holding either the estimate or the measured value - a **prefix-sum offset table**, where entry `i` is the summed height of everything before item `i` - **binary search** over that table to answer "which item is at this scroll position" ```js function indexAtOffset(offsets, scrollTop) { let lo = 0, hi = offsets.length - 2; while (lo < hi) { const mid = (lo + hi + 1) >> 1; if (offsets[mid] <= scrollTop) lo = mid; else hi = mid - 1; } return lo; } ``` ## Estimate, then measure, then correct The standard algorithm runs three phases continuously: 1. **Estimate.** Every unmeasured item gets a provisional height from an estimator. The total size is the sum of estimates and measurements, so the scrollbar is approximately right from the first frame. 2. **Measure.** When an item mounts, the virtualizer reads its real box — a ref callback plus `ResizeObserver`, or an explicit measure call the library provides — and writes the value into the cache. 3. **Correct.** The offset table is rebuilt from the changed index onward, the spacer's total height changes, and the window is recomputed. The consequence is that total height is *unstable*: it converges as more of the list has been seen, and a badly wrong estimator makes the scrollbar thumb visibly grow or shrink while the user scrolls. A good estimator — the median of a sample of real rows, not a round number you liked — is the cheapest fix for most complaints about jumpy scrollbars. ## The scroll-anchoring problem This is the failure an interviewer is really probing for. Correcting an item *below* the viewport is invisible: content further down moves, but nothing on screen shifts. Correcting an item *above* the viewport moves everything below it, including the pixels the user is currently reading. Scrolling upward is therefore the bad direction: previously unmeasured items enter, get measured, and their delta pushes the content you are looking at. Virtualizers handle this by anchoring — remembering an item and its offset within the viewport, and after a measurement pass adjusting `scrollTop` by the accumulated delta so the anchor stays visually still. If you hand-roll a virtualizer, this is the part you will get wrong. If you use a library, this is the behaviour to test explicitly: scroll fast into the middle, then scroll up, and watch whether text stays put. ## Cache invalidation A measured height is valid only for the content and the width it was measured at. Four events invalidate it: - **Container width changes** (window resize, sidebar toggle). Every wrapped-text row can change height, so the whole cache is suspect. - **The item's data changes** — an edited message, an expanded "show more". - **Reordering, insertion or deletion.** Key the cache by a stable item id rather than by index, or heights follow positions instead of records. - **Late-arriving content**, most often images and embeds that load after first paint. react-window's `VariableSizeList` makes this explicit with `resetAfterIndex(index)`, which discards cached sizes from that index on. Headless virtualizers expose an equivalent remeasure call. Forgetting to invalidate produces the signature bug: rows overlapping or leaving gaps after a resize. ## Practical mitigations - **Reserve space for media.** Give images intrinsic width and height attributes or a CSS `aspect-ratio` so the row's height is known before the bytes arrive. This removes the largest source of post-measurement jumps. - **Measure at the right width.** Do not measure inside a container that is still animating open. - **Prefer content-derived estimates.** For chat, estimating from character count and known line height beats a constant by a wide margin. - **Consider making rows uniform.** Clamping to a fixed number of lines, or moving overflow behind a control that opens a detail panel, converts the whole problem back into the fixed-height case. That is a legitimate product answer and a strong one to offer. - **Accept that scroll-to-index is approximate.** Targeting an unmeasured item lands near it, not on it; libraries scroll, measure and correct, which can take a frame or two.