React data grid nasıl seçilir

Her data grid'in özellik listesinde sıralama, filtreleme, gruplama, sanal kaydırma ve Excel export vardır. Yani ilk hafta kuracağınız karşılaştırma tablosu baştan aşağı yeşil tik olur ve seçim yapmanıza yardımcı olmaz.

Bu kütüphaneleri asıl ayıran şey sonra ortaya çıkar: bir milyon satırda, lisansın dolduğu gün, bir tasarımcı ilk kez farklı satır yüksekliği istediğinde, ya da seçtiğiniz bileşenin kilitli bir kurumsal CSP içinde çalışması gerektiğinde.

Onun yerine sorulmaya değer sorular aşağıda. Bu işlerden birini biz de üretiyoruz; dolayısıyla bunu tarafsız bir derleme değil, bilgili bir görüş olarak okuyun — ama aşağıdaki her kontrolü, bize inanmak zorunda kalmadan, herhangi bir aday üzerinde kendiniz çalıştırabilirsiniz.

1. En büyük veri kümenizin dibinde ne oluyor?

Gerçekçi olarak sahip olacağınız en büyük tabloyu yükleyin, en alta kadar kaydırın ve son satırları sayın.

Basit görünüyor. Bozuk bir sanal kaydırıcıyı bulmanın en güvenilir yolu bu, çünkü tarayıcılar bir elemanın ne kadar uzun olabileceğini sessizce sınırlar — Chromium'da yaklaşık 33,5 milyon cihaz pikseli, Firefox'ta bunun yarısı kadar. Satırları piksellere birebir eşleyen bir grid, satırları bitmeden kaydırma çubuğunu bitirir ve son birkaç satıra ulaşılamaz.

Aynısını %125 ekran ölçeklemesinde tekrarlayın. Sınır cihaz pikseli cinsinden; %100'de saklanan hata orada ortaya çıkar.

2. Gerçekte kaç DOM düğümü tutuyor?

Geliştirici araçlarını açın, çizilen satırları sayın. Sanallaştırma iddia eden bir grid, veri boyutundan bağımsız olarak yirmi küsur satır tutmalı. Bazıları yüzlerce tutar; 10.000 satırda sorun değil, bir milyonda çile.

Hazır oradayken, tüm veri yüklüyken filtreye yazın ve düşen kareleri izleyin. Sanallaştırma çizim işini sınırlar; her satır üzerinden geçen senkron bir döngüye hiçbir şey yapmaz — büyük veride gecikme genelde orada yaşar.

3. Worker kurulumu neyi gerektiriyor?

Grid işi ana iş parçacığının dışına taşıyorsa — ölçek büyüdükçe taşımalı — bunun kurulum anında size neye mal olduğunu öğrenin. Kimisi public/ içine dosya kopyalamanızı ister, kimisi bundler'a özel bir import, kimisi her çatı için ayrı kurulum.

Bu adım sadece bir zahmet değil: yükseltmede bozulur, geliştirme ve canlı derlemelerinizde farklı davranır ve ekibe katılan herkesi şaşırtır. Hiçbir yapılandırma olmadan çalışıp çalışmadığını sorun; çalışmıyorsa, talimatın sizin bundler'ınız için nasıl göründüğünü isteyin.

4. Lisans doğrulaması çevrimdışı mı yapılıyor?

Ticari grid'lerde en uzun kuyruklu soru bu. Sağlayıcının sunucusuna giden bir lisans kontrolü, canlı uygulamanızı o sağlayıcının ayakta olmasına bağımlı kılar — sonsuza kadar, her sayfa yüklemesinde, müşterilerinizin kriz anları dahil.

Çevrimdışı doğrulamanın (pakete gömülü genel anahtarla yerel kontrol edilen imzalı bir anahtar) bunların hiçbiri yoktur. Açıkça sorun; "lisans anahtarı" ifadesi hangi modeli aldığınızı söylemez.

5. Lisans geçersizken ne oluyor?

Anahtar eksik, süresi dolmuş veya yanlışken kullanıcının ne gördüğünü sorun. İki cevap var ve aradaki fark herhangi bir özellikten daha önemli.

Yumuşak hata: grid çizilir, çalışır ve filigran gösterir. Spam klasörüne düşen bir yenileme e-postası size ekranda bir işaret olarak mal olur.

Sert hata: bileşen hata fırlatır. Artık uygulamanızın erişilebilirliği faturalama durumunuza bağlıdır ve gecikmiş bir fatura canlı panoyu düşürür.

Bunu satın almadan önce yazılı olarak alın.

6. Yazacağınız API gerçekten belgelenmiş mi?

Özellik listeleri "düzenleme" der. Kodla düzenlemeyi başlatabilir misiniz, doğrulama motorda mı yoksa yalnızca arayüzde mi çalışır, geri almanın genel bir API'si var mı, hangi olaylar hangi sırayla tetiklenir — bunları nadiren söyler.

İhtiyacınız olduğunu bildiğiniz bir akış seçin — mesela "kullanıcı hücreyi düzenler, sunucuda doğrularız, sonra geri alırız" — ve destek almadan, yalnızca dokümantasyona bakarak yazmayı deneyin. Yazamıyorsanız, entegrasyon süreniz konuşuyor demektir.

7. Temalandırma nasıl yapılıyor?

Temaların CSS özel değişkenleri mi yoksa çatallayacağınız derlenmiş bir stil dosyası mı olduğunu sorun. Birincisi tasarım sisteminizin fikir değiştirmesine dayanır; ikincisi bakımını üstlendiğiniz bir yamaya dönüşür.

Test etmeye değer iki nokta: satır yüksekliğini değiştirin ve bir şeyin hizadan çıkıp çıkmadığına bakın; bir popup açın (filtre, sütun seçici) ve temayı devraldığını doğrulayın — popup'lar genelde grid'in DOM'unun dışına taşınır ve temalandırma en çok orada sızar.

8. Sizin CSP'nizde çalışabiliyor mu?

Bir bankaya, hastaneye veya güvenlik incelemesi olan herhangi bir yere teslim ediyorsanız, önce Content-Security-Policy'nizi bulun ve grid'in neye ihtiyaç duyduğunu kontrol edin. Blob worker'lar worker-src blob: ister. Satır içi stiller style-src 'unsafe-inline' veya nonce ister. Formül ayrıştırmak için çalışma anında eval, çoğu böyle ortamda kesin hayırdır.

Bunu güvenlik incelemesi sırasında öğrenmek, öğrenilebilecek en pahalı andır.

---

Kendimiz hakkında kısa ve dürüst bir not

Bu sorulara böyle cevap veriyoruz çünkü her birine zor yoldan çarptık. Kendi grid'imiz birinci soruda düzeltme oturana kadar üç kez kaldı. Worker'larımız gömülü olduğu için üçüncü sorunun bizde bir cevabı yok. Doğrulama çevrimdışı ve hata bilinçli olarak yumuşak.

Zayıf olduğumuz yer: yerleşik seçeneklere kıyasla çok daha kısa geçmişi olan küçük bir ekibiz ve ekosistemimiz — üçüncü taraf örnekler, Stack Overflow cevapları, API'yi zaten bilen insanlar — buna bağlı olarak ince. Bu gerçek bir maliyet ve tartmalısınız.

İyi haber şu: sekiz sorunun hiçbiri kimseye güvenmeyi gerektirmiyor. Hepsi, gerçek bir veri kümesi ve açık geliştirici araçlarıyla bir öğleden sonrada cevaplanabilir.

Hepsini bizimkine karşı çalıştırabilirsiniz: playground her özelliği kendi sayfasında gösteriyor, performans demosu tarayıcıda iki milyon satıra çıkıyor.