Server Components: İstemci Sınırını Nereye Çizmeli

App Router yeterince uzun süredir varsayılan; kullanılıp kullanılmayacağı tartışması bitti. Hâlâ netleşmemiş olan şey, sunucu ile istemci arasındaki sınırın nereye konacağı. Bu sorunun genel bir cevabı yok. Bileşen başına bir cevabı var.

On altı üründen sonra nasıl karar verdiğim ve nerede yanıldığım.

Varsayılan sunucudur, sebebi ağırlık

Server Component HTML gönderir. Client Component ise HTML artı onu etkileşimli yapacak JavaScript artı ihtiyaç duyduğu verinin serileştirilmiş hali. İkincisi kötü değil, sadece daha pahalı, ve bu maliyeti metroda telefon tutan biri ödüyor.

Yani soru asla "bu Client Component olabilir mi" değil. "Olmak zorunda mı" sorusu. Etkileşim, tarayıcı API'leri, tıklamadan sonra yaşayan durum. Geri kalan her şey varsayılan olarak sunucuda kalır ve kimsenin denetlemesine gerek kalmadan paket küçük kalır.

Sınır aşağı iner, yukarı değil

İlk yıl tekrar tekrar yaptığım hata, içindeki tek bir şeyin tıklama handler'ına ihtiyacı var diye bütün sayfayı Client Component işaretlemekti. O anki en ucuz çözüm, sonrasındaki en pahalısı; çünkü altındaki her şey de istemciye geçiyor.

Doğrusu sınırı gidebildiği kadar derine itmek. Sayfa sunucuda kalır, layout sunucuda kalır, ve onClick'e ihtiyaç duyan tek buton altında hiçbir şey olmayan kendi Client Component'i olur. Server Component'ler Client Component render edebildiği için, çoğunlukla statik bir sayfa üç etkileşimli ada maliyetine iner, bir sayfa maliyetine değil.

Veri prop olarak iner, istemcide fetch ile değil

Sınır derinleşince bir desen kendiliğinden çıkıyor: sunucuda çek, sonucu aşağı geçir.

Bu, koca bir iş kategorisini ortadan kaldırıyor. Render'dan önce zaten elinizde olan veri için yükleniyor durumu yok. Bağlandıktan sonra gidip bir şey getiren effect yok. Bileşenin render edip, sonra sorup, sonra tekrar render ettiği şelale yok.

İstemci tarafında fetch'e hâlâ başvurduğum yer gerçekten dinamik veri: sürekli yoklanan bir şey, kullanıcının hızlıca filtrelediği bir şey, soket üzerinden güncellenen bir şey. Bu gerçek bir kategori ve ilk bakışta göründüğünden küçük.

Server Actions beklediğimden fazla kod sildi

Bir form eskiden şu demekti: API rotası, fetch, yükleniyor bayrağı, hata durumu, ve mutasyonun değiştirdiği şeyin elle tazelenmesi. Server Action bunu sunucuda çalışan bir fonksiyon ile bir revalidate çağrısına indiriyor.

Akılda tutulacak iki şey var. Editörünüzde nasıl görünürse görünsün bu bir genel uç nokta, yani her rota gibi yetkilendirme istiyor: bugün onu yalnızca sizin formunuzun çağırması bir güvenlik özelliği değil. Bir de revalidation, insanların unuttuğu kısım; çünkü mutasyon başarılı olurken sayfa eski veriyi göstermeye devam eder ve bu, eksik bir önbellek temizliği gibi değil yazma hatası gibi okunur.

Gerçekten zorlayan yer

Üçüncü taraf bileşenler. Import anında tarayıcı bekleyen her şey bir istemci sınırının arkasına alınmak zorunda ve bazı kütüphaneler bunu olması gerekenden zorlaştırıyor. Bu, işin vergisi ve gerçek.

Hata ayıklama da eskisinden zor. Bir hata artık sunucudaki render'dan, istemcideki render'dan ya da ikisi arasındaki serileştirmeden gelebilir ve yığın izi farkı her zaman açık etmiyor. Aynı bileşeni iki yerde render etmek küçük bir değişiklik gibi duruyor, değil.

Vereceğim kural

Sunucuda başlayın. Bir şey sizi zorlayana kadar istemciye geçmeyin, geçtiğinizde de mümkün olan en küçük parçayı taşıyın.

Performans kılavuzu gibi duruyor, aslında bir bakım kılavuzu. İstemci sınırının dar çizildiği bir sayfa, dosya ağacına bakarak hangi kısımların tarayıcıda çalışmak zorunda olduğunu görebildiğiniz bir sayfadır. Altı ay sonra bu, herhangi bir paket boyutu rakamından değerlidir.