TanStack udostępnił wersję beta Table v9, biblioteki typu data-grid, która pozwala programistom wybierać tylko te funkcje, których potrzebują. Rozmiary paczek zmniejszają się do około 5 KB, a opóźnienia Interaction-to-Next-Paint (INP), które sprawiały, że sortowanie lub filtrowanie wydawało się ociężałe, znikają.

Dlaczego ta zmiana jest ważna

W wersji v8 biblioteka dostarcza każdy element logiki siatki — sortowanie, filtrowanie, paginację, wybór wierszy, grupowanie — niezależnie od tego, czy projekt z nich korzysta. Ten dodatkowy kod działa na głównym wątku, zwiększa rozmiar paczki i dodaje opóźnienia do działań użytkownika. W przypadku dashboardów wymagających szybkich i responsywnych tabel, kilka milisekund opóźnienia może obniżyć wynik INP do poziomu uznawanego za słaby.

Co v9 robi inaczej

  • Moduły funkcji typu opt-in – Importuj tylko te elementy, których faktycznie używasz. Jeśli pominiesz sortowanie, kod odpowiedzialny za sortowanie nigdy nie trafi do paczki.
  • Integracja z TanStack Store – Zarządzaj stanem za pomocą precyzyjnego (fine-grained) store'a, dzięki czemu aktualizacja jednego wiersza nie powoduje pełnego ponownego renderowania paska filtrów ani innych niepowiązanych elementów interfejsu.
  • Zmniejszone zużycie pamięci – Mniejsza liczba obiektów i tablic odciąża stertę JavaScript (JS heap) podczas długich sesji.

Zmiany te przekładają się na mniejszy rozmiar pobierania (biblioteka może ważyć blisko 5 KB dla prostej listy) oraz płynniejszą interakcję, gdy siatka jest obciążona.

Kto na tym zyska

  • Zespoły frontendowe budujące narzędzia wewnętrzne, panele administracyjne lub dashboardy SaaS, gdzie tabele są głównym elementem interfejsu.
  • Strony skoncentrowane na wydajności, które monitorują Core Web Vitals; niższy wynik INP bezpośrednio poprawia tę metrykę.

Czego v9 nie naprawi

Ulepszenia dotyczą kodu, nad którym masz kontrolę. Nie przyspieszą one magicznie strony pobierającej ogromny ładunek JSON, ani nie zrekompensują kosztów ciężkich skryptów zewnętrznych. Duże zestawy danych nadal wymagają odpowiedniej paginacji, a opóźnienia sieciowe pozostają osobnym problemem.

Praktyczna ścieżka migracji

  1. Zidentyfikuj najcięższe tabele – Szukaj list zamówień, siatek magazynowych lub widoków CRM, które już teraz wykazują zauważalne opóźnienia.
  2. Ustal bazowe metryki – Zanim wprowadzisz jakiekolwiek zmiany, zarejestruj INP oraz czas trwania długich zadań (long-task durations) na tych stronach.
  3. Migruj jedną siatkę na raz – Zastąp import z v8 zestawem modułów z v9, włączając tylko te funkcje, których faktycznie używa dany ekran.
  4. Unikaj paczki typu „wszystko w jednym” stockFeatures – Pobranie domyślnego zestawu funkcji niweluje cel oszczędzania rozmiaru.
  5. Ponownie przetestuj interakcje – Ponownie zmierz sortowanie, filtrowanie i wybór, aby potwierdzić zysk wydajnościowy.

Kontrargument: to nie jest rozwiązanie idealne

Niektórzy programiści mogą oczekiwać, że v9 rozwiąże każdy problem z ociężałym interfejsem. W rzeczywistości zyski biblioteki są ograniczone ilością kodu niestandardowego, który można usunąć. Jeśli wąskim gardłem tabeli jest sama liczba wierszy lub niewydajne API serwera, redukcja rozmiaru paczki będzie miała ograniczony wpływ.

Na co zwrócić uwagę w następnej kolejności

Podsumowanie: TanStack Table v9 daje konkretny sposób na zaprzestanie płacenia za nieużywane funkcjonalności siatki. Importując tylko potrzebne moduły i korzystając z precyzyjnego store'a, możesz zaoszczędzić kilka kilobajtów w swoich paczkach i zapewnić znacznie szybszą interakcję z tabelami — pod warunkiem, że połączysz aktualizację z rozsądnymi strategiami obsługi danych.