TanStack, geliştiricilerin yalnızca ihtiyaç duydukları özellikleri seçebilmelerine olanak tanıyan bir veri ızgarası (data-grid) kütüphanesi olan Table v9'un betasını yayınladı. Paket boyutları yaklaşık 5 KB'a düşüyor ve sıralama veya filtreleme işlemlerini hantal hissettiren etkileşimden sonraki boyama (interaction-to-next-paint - INP) gecikmeleri ortadan kalkıyor.

Bu değişiklik neden önemli?

v8'de kütüphane; bir proje bunlardan herhangi birini kullansa da kullanmasa da sıralama, filtreleme, sayfalama, satır seçimi ve gruplandırma gibi tüm ızgara mantığı parçalarını beraberinde getirir. Bu fazladan kod ana iş parçacığında (main thread) çalışır, paket boyutunu şişirir ve kullanıcı eylemlerine gecikme ekler. Hızlı ve duyarlı tablolara ihtiyaç duyan paneller (dashboards) için birkaç milisaniyelik gecikme bile INP puanını düşük bir aralığa çekebilir.

v9 neleri farklı yapıyor?

  • Seçmeli (Opt-in) özellik modülleri – Yalnızca gerçekten kullandığınız parçaları içe aktarın. Sıralamayı atlayın ve sıralama kodu pakete hiç dahil edilmesin.
  • TanStack Store entegrasyonu – Durumu (state) hassas bir depolama birimi (fine-grained store) ile yönetin; böylece tek bir satırı güncellemek, filtre çubuğunun veya diğer ilgisiz kullanıcı arayüzlerinin (UI) tamamen yeniden oluşturulmasını (re-render) tetiklemez.
  • Azaltılmış bellek ayak izi – Daha az nesne ve dizi, uzun oturumlar sırasında JavaScript heap üzerindeki baskıyı hafifletir.

Bu değişiklikler, daha küçük bir indirme boyutuna (basit bir liste için kütüphane 5 KB civarında kalabilir) ve ızgara yoğun olduğunda daha pürüzsüz bir etkileşime dönüşür.

Kimler fayda sağlar?

  • Frontend ekipleri; tabloların temel kullanıcı arayüzü öğesi olduğu dahili araçlar, yönetim panelleri veya SaaS panelleri inşa edenler.
  • Performans odaklı siteler; Core Web Vitals değerlerini izleyenler; düşük bir INP, bu metriği doğrudan iyileştirir.

v9 neleri düzeltmez?

İyileştirmeler, kontrol ettiğiniz kodu hedefler. Devasa bir JSON veri yükü çeken bir sayfayı sihirli bir şekilde hızlandırmayacağı gibi, ağır bir üçüncü taraf betinin maliyetini de dengelemeyecektir. Büyük veri setleri hâlâ uygun sayfalama gerektirir ve ağ gecikmesi ayrı bir sorun olmaya devam eder.

Pratik bir geçiş yolu

  1. En ağır tabloları belirleyin – Halihazırda fark edilir gecikmeler gösteren sipariş listeleri, envanter ızgaraları veya CRM görünümlerine bakın.
  2. Temel metrikleri yakalayın – Herhangi bir değişiklik yapmadan önce bu sayfalardaki INP ve uzun görev (long-task) sürelerini kaydedin.
  3. Her seferinde bir ızgarayı taşıyın – v8 içe aktarmasını (import), yalnızca ekranın gerçekten kullandığı özellikleri etkinleştirerek v9 modül setiyle değiştirin.
  4. Her şeyi kapsayan stockFeatures paketinden kaçının – Varsayılan özellik setini çekmek, boyut tasarrufu amacına aykırıdır.
  5. Etkileşimleri yeniden test edin – Performans kazancını doğrulamak için sıralama, filtreleme ve seçme işlemlerini tekrar ölçün.

Karşı görüş: mucizevi bir çözüm değil

Bazı geliştiriciler v9'un her hantal kullanıcı arayüzü sorununu çözeceğini bekleyebilir. Gerçekte, kütüphanenin sağladığı kazanımlar, budayabileceğiniz özel kod miktarıyla sınırlıdır. Eğer bir tablonun darboğazı satır sayısının çokluğu veya verimsiz bir sunucu API'si ise, paket boyutu azaltılması sınırlı bir etkiye sahip olacaktır.

Sırada ne var?

Özet: TanStack Table v9, kullanılmayan ızgara işlevselliği için ödeme yapmayı durdurmanız için size somut bir yol sunar. Yalnızca gerekli modülleri içe aktararak ve hassas bir depolama birimi kullanarak, paket boyutunuzdan birkaç kilobayt tasarruf edebilir ve —yükseltmeyi mantıklı veri işleme stratejileriyle birleştirdiğiniz sürece— fark edilir derecede daha hızlı tablo etkileşimleri sunabilirsiniz.