Использовал ли ты библиотеки для виртуализации списков в React

Что проверяют

Работали ли вы с большими списками и понимаете ли, почему они тормозят и что даёт виртуализация. Следом спрашивают про строки разной высоты и о том, что теряется, когда большей части строк нет в DOM.

Как отвечать

Начните со своего случая: сколько строк, насколько тяжёлая каждая, что показал профайлер. Цифры до и после берите из своих замеров в React Profiler или вкладке Performance, а не округлённые проценты. Если опыта не было, так и скажите и опишите подход: сначала замер, потом выбор решения.

Суть виртуализации: в DOM живут только видимые строки плюс небольшой запас (overscan), а контейнер получает полную высоту, чтобы полоса прокрутки была честной. Прокрутку библиотека отслеживает сама. Инструменты:

• react-window: лёгкая, проще всего работает со строками известной высоты;
• @tanstack/react-virtual: headless-хук useVirtualizer, разметку пишете сами. Динамическую высоту даёт measureElement, а estimateSize задаёт начальную оценку;
• react-virtuoso: сама измеряет строки произвольной высоты, умеет группы с прилипающими заголовками и сценарии чата;
• react-virtualized: старая и тяжёлая, в новых проектах её обычно не берут.

Бесконечную подгрузку добавляют через IntersectionObserver или колбэк конца списка. Иногда хватает CSS: content-visibility: auto с contain-intrinsic-size пропускает отрисовку невидимых блоков, не удаляя их из DOM.

Где спотыкаются

Виртуализируют список из пятидесяти строк. Тормоза там от лишних перерисовок, и лечат их memo и стабильными ключами, а не новой библиотекой.

Задают фиксированную высоту строкам, у которых она меняется, и получают прыжки и наезды при прокрутке.

Не думают о цене: поиск браузера по Ctrl+F не находит невидимые строки, скринридер не знает размера списка без aria-setsize и aria-posinset, а позицию прокрутки при возврате на страницу приходится восстанавливать вручную.