Endge

Тема

Виртуализация списков и тяжёлых таблиц ​

Одна потребность: списки и таблицы с большим количеством строк (тысячи и более) не должны рендерить все DOM-узлы; только видимая область и буфер должны быть в DOM. Это критично для производительности и отзывчивости UI в enterprise-сценариях (большие гриды, журналы, справочники).

Зачем это нужно (мировой опыт) ​

  • React Virtualized, TanStack Virtual, react-window: рендер только видимых элементов + небольшой overscan; константная сложность по количеству DOM-узлов независимо от размера данных.
  • AG Grid, TanStack Table (virtualization): тяжёлые таблицы в enterprise по умолчанию виртуализированы по строкам (и при необходимости по столбцам).
  • Без виртуализации: 10 000 строк = 10 000+ узлов в DOM, долгий первый рендер, подвисания при скролле и при обновлении данных. На слабых устройствах и в больших сессиях это неприемлемо.

Текущее состояние ​

  • Используется RevoGrid (@revolist/vue3-datagrid) внутри нового SFC Table renderer; библиотека предоставляет виртуализацию строк из коробки.
  • Есть зависимости @tanstack/vue-virtual, @tanstack/virtual-core — при необходимости можно виртуализировать кастомные списки (деревья, простые списки), где RevoGrid не используется.
  • Не все списки в приложении виртуализированы: деревья домена (Domain_Widget), списки в инспекторах, выпадающие списки с большим числом опций — могут рендерить все элементы. При росте данных (например, тысячи типов или запросов) возможны тормоза.
  • Нет единого стандарта: «все списки выше N элементов должны использовать виртуализацию»; нет обёртки/компонента «виртуальный список» в дизайн-системе платформы для единообразного использования.

Что сделать ​

1. Зафиксировать использование RevoGrid для тяжёлых таблиц ​

  • Все таблицы с потенциально большим числом строк (данные из запросов, журналы, справочники) должны использовать RevoGrid или другой виртуализированный грид. Не рендерить тысячи строк через обычный HTML table с v-for.
  • Документировать в компонентах и в виджете таблицы: RevoGrid даёт виртуализацию; настройки (высота строки, overscan) при необходимости тюнить под сценарий.

2. Виртуализация не-табличных списков ​

  • Списки с большим числом элементов (например, селекты с сотнями/тысячами опций, плоские списки в админке) — использовать виртуализированный список (например, на базе @tanstack/vue-virtual или аналога): рендер только видимой области + overscan.
  • Деревья (например, дерево домена): при очень большом числе узлов рассмотреть виртуализацию по уровням или «виртуальное дерево» (раскрытые ветки как плоский виртуализированный список). Оценить по реальным объёмам; при необходимости ввести лимит отображения с «показать ещё» или поиском.

3. Порог и стандарт платформы ​

  • Ввести правило: при ожидаемом числе элементов выше N (например, 100–200) использовать виртуализированный компонент. N зафиксировать в документации или в конфиге.
  • Общий компонент «VirtualList» (или «VirtualSelect») в @endge/ui-vue или в дизайн-системе: единый API (данные, высота строки, шаблон элемента), внутри — виртуализация. Использовать его везде, где нужен длинный список.

4. Производительность и замеры ​

  • При добавлении новых списков/таблиц с большими данными проверять в браузере: число DOM-узлов при скролле не должно расти пропорционально размеру данных. При необходимости добавлять тесты производительности (например, рендер 10k строк, время до интерактивности).
  • Документировать рекомендации: размер страницы при пагинации на бэкенде, использование виртуализации на фронте, избегание тяжёлых вычислений в ячейках.

Риски и ограничения ​

  • Виртуализация меняет поведение скролла и доступность (скринридер видит только видимые строки); для a11y нужны рекомендации (см. Accessibility_A11y). Деревья с виртуализацией сложнее в реализации; оценивать по реальным объёмам.

Вывод ​

  • RevoGrid уже даёт виртуализацию таблиц; зафиксировать его использование для всех тяжёлых гридов и не допускать невиртуализированных больших таблиц.
  • Ввести виртуализацию для длинных не-табличных списков (VirtualList/VirtualSelect на базе TanStack Virtual или аналога).
  • Стандарт платформы: при числе элементов выше порога — только виртуализированные компоненты; общий компонент и документированный порог.
  • Проверка производительности при изменении списков/таблиц с большими данными.