virtualizationlisted

# Virtualization ## Decide with the real maximum, not today's data The question is not "is this list long?" but **"what is the largest number of items this can hold?"** A list that is fine at 20 rows and unusable at 5,000 is a defect waiting for the customer with 5,000. Get the number from the data-shape facts the exploration recorded. If nobody knows the maximum, **that is the finding** — an unbounded render path is a defect regardless of what today's data happens to contain. ## Thresholds, roughly - **Under ~100 simple rows** — render them all. Virtualization costs complexity it does not repay. - **100–500** — depends on row cost. A row with one text node is cheap; a row with a chart, an avatar, and five interactive controls is not. - **Above ~500** — virtualize, or paginate. **Consider the alternatives first.** Pagination, "load more", or a server-side query with a limit are often better answers than virtualization: they are simpler, they bound the data transfer too, and they do not break the behaviours below. Virtualization is the right answer when the user genuinely needs to scroll a long list continuously. ## What virtualization breaks, and what to do about it This is the part that gets skipped, and it is why virtualized lists so often ship with real defects. **Ctrl+F stops working.** Only rendered rows are in the DOM, so the browser's find cannot see the rest. If in-page search matters, provide your own search — and say so, because users will try the browser's