Kısmi Hydration (Partial Hydration) Nedir?
Kısa tanım
Kısmi hydration (partial hydration), sunucuda veya derleme sırasında üretilmiş bir sayfada yalnızca etkileşim gerektiren bileşenlerin JavaScript ile hydrate edildiği, geri kalan içeriğin düz HTML olarak bırakıldığı yaklaşımdır. Bu fikrin sayfa mimarisi düzeyindeki karşılığına islands architecture (ada mimarisi) denir: statik bir sayfanın içinde bağımsız çalışan etkileşimli adalar. Amaç, tarayıcıya gönderilen ve çalıştırılan JavaScript miktarını azaltmaktır.
Diğer adları: Partial Hydration, islands architecture, ada mimarisi, component islands
Tam hydration'ın çözmediği sorun
Klasik sunucu taraflı render'da sayfanın HTML'i hazır gelir, ama hydration sırasında framework tüm bileşen ağacını tarayıcıda yeniden çalıştırır. Uzun bir blog yazısında etkileşimli olan tek şey belki menü düğmesi ve yorum formudur; buna rağmen başlıkların, paragrafların ve alt bilginin bileşen kodu da indirilir ve çalıştırılır. Maliyet sayfanın ne kadar etkileşimli olduğuyla değil, ne kadar büyük olduğuyla orantılı büyür. Kısmi hydration bu orantıyı tersine çevirir: hiç etkileşim içermeyen bölümler için tarayıcıya JavaScript gönderilmez.
Ada mimarisi (islands architecture)
"Bileşen adası" ifadesini 2019'da Etsy'nin frontend mimarı Katie Sylor-Miller kullandı; Preact'in yaratıcısı Jason Miller, Ağustos 2020'de yazdığı bir makaleyle fikri genişletip "islands architecture" adıyla yaygınlaştırdı. Modelde sayfa, sunucuda üretilmiş statik HTML'den oluşan bir denizdir; etkileşim gereken her bileşen bu denizde bağımsız bir adadır. Her ada kendi kodunu yükler, kendi zamanında hydrate edilir ve bir adadaki hata ya da gecikme diğerlerini bekletmez.
Bir haber sayfasını düşünün: üst menü, arama kutusu ve yorum formu ada; makale metni, görseller, ilgili haber listesi ve alt bilgi düz HTML. Ziyaretçi metni okumaya başladığında henüz hiçbir ada hydrate edilmemiş olabilir ve bu bir sorun yaratmaz.
Astro örneği: ne zaman hydrate edilsin?
Astro bu modeli varsayılan olarak uygular: bileşenler HTML ve CSS'e dönüştürülür, istemci JavaScript'i atılır. Bir bileşenin etkileşimli olması gerekiyorsa client:* yönergesiyle açıkça işaretlenir ve yönerge, hydration'ın zamanlamasını da belirler:
---
import Header from "../components/Header.astro";
import Sepet from "../components/Sepet.jsx";
import Arama from "../components/Arama.jsx";
import Yorumlar from "../components/Yorumlar.jsx";
---
<Header /> <!-- yalnızca HTML -->
<Sepet client:load /> <!-- sayfa yüklenince -->
<Arama client:idle /> <!-- tarayıcı boşa çıkınca -->
<Yorumlar client:visible /> <!-- görünür alana girince -->Astro ayrıca server:defer yönergesiyle "sunucu adaları" sunar: kullanıcıya özel bir avatar veya stok bilgisi gibi dinamik bölümler, sayfanın geri kalanını bekletmeden sunucuda ayrıca render edilip yerine yerleştirilir. Ayrıntılar Astro dokümantasyonunda.
Benzer adlı kavramları ayırmak
| Kavram | Cevapladığı soru |
|---|---|
| Kısmi hydration | Hangi bileşenler hydrate edilecek? |
| Aşamalı (progressive) hydration | Bileşenler hangi sırayla ve ne zaman hydrate edilecek? |
| Seçici (selective) hydration | React'te Suspense sınırlarıyla ayrılmış bölümlerden hangisine öncelik verilecek? |
| Resumability | Hydration hiç yapılmadan, sunucunun bıraktığı yerden devam edilebilir mi? (Qwik) |
React Server Components da React ağacının içinde benzer bir etki yaratır: sunucu bileşenlerinin kodu tarayıcıya hiç gitmez, yalnızca istemci bileşenleri hydrate edilir. Bir başka sık karışıklık da aşamalı geliştirme (progressive enhancement) ile aşamalı hydration'ın aynı şey sanılmasıdır. Birincisi sayfanın JavaScript olmadan da temel işlevini koruması ilkesidir; ada mimarisi bu ilkeyle iyi uyum sağlar, ama onu kendiliğinden garanti etmez.
Ödünleşimler
Adalar birbirinden bağımsız olduğu için aralarında durum paylaşmak ek iş ister: sepete ekleme düğmesiyle başlıktaki sepet sayacı farklı adalardaysa ortak bir depo veya özel olaylar gerekir. Sayfanın büyük kısmının etkileşimli olduğu panel tarzı uygulamalarda ada sayısı çoğalır ve modelin avantajı azalır; böyle projelerde SPA yaklaşımı daha doğal olabilir. İçerik ağırlıklı sitelerde ise ana iş parçacığını meşgul eden kod azaldığı için etkileşim gecikmesi, yani INP, genellikle olumlu etkilenir.