← Все статьи

TanStack Table v9: платите только за те возможности таблицы, которые включаете

Стабильный v9 спустя четыре года после v8: модульные возможности, TanStack Store, до 86% меньше памяти на миллионе строк и десять адаптеров фреймворков.

TanStack Table v9: платите только за те возможности таблицы, которые включаете
Содержание

Коротко

В выпуске React Status #486 первой новостью стоит стабильный TanStack Table v9 — спустя больше четырёх лет после v8. Кевин Ван Котт (с 2022 он ведёт библиотеку вместо Таннера Линсли) пересобрал ядро: возможности регистрируются явно и выкидываются из бандла, если ими не пользуетесь; состояние живёт на TanStack Store; на миллионе строк в замере команды удержанная куча падает примерно с 2,71 ГБ до ~380 МБ. Безголовая модель таблицы та же; ломается способ сборки «системы таблиц» в продукте. Рядом в дайджесте — обзор Vercel по Next.js 16.3 и червь в пакете keyv; это фон недели, не тема релиза таблицы.

Что произошло

Официальный разбор — в блоге TanStack (4 августа 2026). Бета два месяца назад обещала в основном внутренний каркас. За бету каркас успели нарастить, и в стабильном списке семь блоков.

Адаптеры: десять фреймворков плюс @tanstack/table-core. Состояние на TanStack Store стыкуется с нативной реактивностью: сигналы, ссылки, руны, computed(). React 18+ дружит с компилятором и даёт тонкие подписки через атомы, селекторы и table.Subscribe. Есть Preact, Vue 3.2+, Solid 1.x (Solid 2 обещают к v10), Svelte 5, Angular 19+, Lit, Alpine, Ember 5.8+ и Octane.

Память: общие прототипы для API строки, столбца, ячейки и шапки вместо копии методов на каждый экземпляр. На миллионе строк × 8 столбцов с постраничной нарезкой удержанная куча в отчёте — около 86% меньше, чем у v8. Среднее время обработки: ядро модели строк −79%, группировка −52%, сортировка −37%, фильтры −34%.

Состояние по-прежнему можно вести через state и on[State]Change или отдать куски внешним атомам. Типы знают, какие возможности зарегистрированы: API фильтра не существует в типах, пока фильтр не включили. Возможности собирают через tableFeatures(): таблица только с постраничной нарезкой не тащит фильтры и группировку. Полный пакет вырос примерно с 14 до 25 КБ в сжатом виде, но средний бандл приложения должен стать меньше. Для продукта целиком — tableOptions() и createTableHook(): общая фабрика таблиц с уже привязанными возможностями и договорённостями по ячейкам.

Из нового: выделение ячеек (прямоугольники, перетаскивание, Shift, несколько диапазонов), объединение ячеек по строкам и столбцам, несколько агрегаций на столбец. Временный мост для React — useLegacyTable с API v8 поверх v9; он устарел, тянет все возможности и раздувает бандл — только чтобы переехать. Для экрана только с постраничной нарезкой официальный пример регистрирует rowPaginationFeature и createPaginatedRowModel() — и больше ничего. Это и есть обещание v9 на практике: средний бандл приложения должен стать меньше, даже если полный пакет вырос с ~14 до ~25 КБ.

Почему это важно

Таблица в продукте редко одна. Обычно это сетка заказов, сетка логов, сетка админки — и в v8 в бандл часто утекало «всё, что умеет библиотека». Явная регистрация возможностей меняет экономику: новый столбец с группировкой платит тот экран, которому она нужна. Смена мейнтейнера объясняет, почему ждали так долго; архитектура заточена под то, чтобы v10 (сводные таблицы, сложные выражения фильтров, Solid 2) не заставляла всех тащить дорожную карту целиком.

Для фронтенда это ещё и урок модульности: «безголовая библиотека» в 2026 году — не только «рисуй сам», но и «подключай только те алгоритмы строк, которые реально гоняете на клиенте». Если сетка виртуализирует сотни тысяч строк, выигрыш по памяти — не микрооптимизация, а разница между вкладкой, которая живёт, и вкладкой, которую убивает браузер. Замеры команды как раз про этот край: на маленьких таблицах экономия почти незаметна, на миллионе строк — уже сотни мегабайт и гигабайты.

На практике

  1. Новый экран сразу пишите на v9: useTable + явный features, не копируйте useReactTable из старых гайдов.
  2. Для миграции читайте гид своего фреймворка; useLegacyTable — короткий мост, не целевое API.
  3. Регистрируйте только нужное: постраничная нарезка на клиенте — rowPaginationFeature и createPaginatedRowModel(), без «на всякий случай» фильтров.
  4. Подписки рисуйте через table.Subscribe / селекторы, а не через перерисовку всей сетки на любое изменение состояния.
  5. Если таблиц в продукте много, вынесите общий createTableHook() со значениями по умолчанию, сортировками и ячейками — отдельные экраны останутся короткими.
  6. Проверьте большие клиентские наборы (сотни тысяч строк с виртуализацией): выигрыш по памяти — главный практический аргумент менять мажор.
  7. Фон дайджеста: обзор Vercel по эффективности Next.js 16.3 имеет смысл пробежать отдельно; пакет keyv и червь по цепочке npm — повод проверить файл блокировок зависимостей, это не часть релиза таблицы.

Итог

TanStack Table v9 — фундамент, а не набор «ещё кнопок в шапке». Платите за включённые возможности, меньше памяти на огромных клиентских сетках, реактивность, близкая к фреймворку, десять адаптеров. Переезд ломает хуки и регистрацию модулей — зато дальше библиотека может расти, не раздувая каждую таблицу в приложении.