Kısa cevap
Hydration, önceden oluşturulmuş HTML üzerine tarayıcıda uygulamanın etkileşimli davranışlarının bağlanması sürecidir.
Nerede işine yarar?
Sunucu ve istemcinin ilk çıktısı uyuşmalıdır. Büyük istemci paketleri indirme ve çalıştırma maliyetini artırabilir. Bu yüzden bütün içerik alanını istemci bileşeni yapmak yerine, gerekli etkileşimi küçük bileşenlere ayırmak değerlendirilebilir.
Tanımdan uygulamaya, kendi denemene.
Bir cümlede uygulaması
Sunucudan gelen yazı listesine tarayıcıda arama ve kategori filtrelerini bağlamak.
Neyle karıştırılmamalı?
Hydration, HTML içeriğinin tamamını mutlaka tarayıcıda sıfırdan üretmek anlamına gelmez.
Ekran göründü. Şimdi davranışı bağlanıyor.
Bir ürün sayfası açılıyor. Başlık, fotoğraf ve renk seçenekleri hemen görünür; tarayıcı JavaScript’i yükledikten sonra seçimler tepki vermeye başlar. Sunucudan gelen HTML’e istemci tarafındaki bileşen davranışının bağlanması, hydration kavramının tipik kullanım alanıdır. İlk görüntü ile etkileşime hazır olma aynı an değildir. Bu aradaki süre uzarsa kullanıcı düğmeye bastığında bir şey olmadığını düşünebilir; sorun yalnız teknik konsolda yaşayan bir ayrıntı değildir.
React gibi sistemlerde başlangıçtaki sunucu çıktısı ile tarayıcının beklediği ilk çıktı uyumlu olmalıdır. Sunucuda günün saati, tarayıcıda başka bir saat dilimi kullanılırsa metin değişebilir. Rastgele değer, pencere genişliği veya yalnız tarayıcıda bulunan kayıt da aynı farkı yaratabilir. Sorunu susturan bir uyarı ayarı, iki farklı ekranın neden üretildiğini açıklamaz. Önce ilk çıktının hangi veriyle oluştuğu belirlenir.
Bir örnek üzerinden düşünelim: kullanıcı son seçtiği para birimini tarayıcıda saklıyor. Sunucu bu tercihi bilmiyorsa ilk sayfa varsayılan para birimiyle gelir. Tarayıcı ilk çizimde hemen başka değer üretirse uyumsuzluk oluşabilir. Tercihi sunucunun erişebileceği bir yöntemle taşımak veya istemciye özgü alanı kontrollü biçimde güncellemek farklı seçeneklerdir. Hangisinin uygun olduğu, kişiselleştirme ve ilk görünüm beklentisine bağlıdır.
Hydration maliyeti, gönderilen etkileşimli kodun kapsamıyla ilişkilidir. Her paragrafın istemci bileşenine dönmesi gerekmez. Sadece ürün seçici, menü veya araç davranış istiyorsa bu sınır küçük tutulabilir. Bir sayfayı sunucuda üretip ardından aynı büyük ağacı tarayıcıda tekrar çalıştırmak, özellikle daha yavaş cihazlarda açılış deneyimini zorlaştırabilir. Önceden görünen içerik ile sonradan gereken davranışı ayırmak tasarımı ve geliştirmeyi birlikte ilgilendirir.
Hidrasyon sorunları yalnız bir hata mesajından ibaret olmayabilir; kullanıcı ilk gördüğü içerikle etkileşimli hâl arasında fark yaşayabilir. Örneğin sunucu farklı bir saat, tarayıcı farklı bir yerel saat üretirse aynı alan değişebilir. İlk görüntüyü mümkün olduğunca tutarlı üretmek, tarayıcıya özgü bilgiyi uygun aşamada eklemek gerekir. Hata uyarısını susturmak gerçek farkın nedenini açıklamaz. Bir seslendirme düğmesi gibi yalnız tarayıcı özelliğine dayanan araçta başlangıçta güvenli bir durum sunulabilir, destek anlaşılınca etkileşim açılabilir. İçeriğin geri kalanı bu küçük aracı beklemek zorunda değildir. Böylece istemci yeteneği olmayan ziyaretçi de temel açıklamayı okuyabilir ve sayfanın anlamını kaybetmez.
HTML’in görünmesi ile uygulamanın hazır olması.
İlk görüntü
Tarayıcı sunucudan gelen başlıkları ve metni gösterebilir. Bu, kullanıcıya hızlı bir başlangıç verir. Ancak özel etkileşimler henüz bağlı değilse ekranın bütün işlevleri hazır değildir. Görsel açılış ölçümünün iyi olması, ilk düğmeye basışın da aynı derecede hızlı ve doğru çalışacağını tek başına göstermez.
Davranışın devralması
İstemci kodu mevcut HTML’i kendi bileşen yapısıyla eşleştirir ve etkileşimleri yönetmeye başlar. Bu sırada başlangıç verisinin tutarlı olması gerekir. Gereksiz yeniden üretim veya uyumsuzluk, hem maliyet hem görünür sorun yaratabilir. Hazır olma durumu bir uygulamanın tamamı için tek bir sayıdan ibaret olmayabilir; farklı parçalar farklı zamanda etkinleşebilir.
İlk HTML ile istemciyi eşleştirmek
Hydration sırasında sunucudan gelen yapı ile istemcinin ilk üretimi uyumlu olmalıdır. Rastgele değer, cihaz saatine bağlı metin veya yalnız tarayıcıda bilinen bir koşul ilk görüntüyü farklılaştırabilir. Etkileşimli alanlar tasarlanırken bu iki aşama ayrı düşünülür; başlangıç içeriği kararlı tutulur.
- İlk render'da zaman ve rastgelelik kaynaklarını kontrol et.
- Tarayıcıya özgü bilgileri uygun istemci aşamasında kullan.
- Geliştirme konsolundaki uyuşmazlıkları gizlemek yerine nedenini düzelt.
Hydration hatası yalnız görsel bir uyarı mı?
Hayır. Uyuşmazlık beklenmeyen yeniden üretim veya yanlış davranışla sonuçlanabilir. Uyarıyı bastırmak yalnız sınırlı ve bilinçli durumlarda düşünülmeli; sunucu ile istemcinin neden farklı içerik ürettiği araştırılmalıdır.
İşin içinde sorulacaklar.
Hydration hatası her zaman sayfayı bozar mı?
Sonuç kullanılan sistemin davranışına ve farkın niteliğine bağlıdır. Bazen küçük bir metin uyumsuzluğu görünür, bazen bileşen ağacı yeniden oluşturulur veya etkileşimler beklenmedik çalışır. Uyarıyı önemsiz saymak yerine hangi verinin farklılaştığı araştırılır. Özellikle form değerleri, kimlikler ve kullanıcıya özel içerik söz konusuysa görüntü doğru görünüyor diye sorun yok kabul edilmez.
Tarayıcıya özel bilgiye hiç bakmamalı mıyız?
Bakabiliriz; mesele hangi aşamada ve hangi başlangıçla bakıldığıdır. Pencere ölçüsü, yerel tercih veya ses desteği gibi bilgiler ilk sunucu çıktısında bilinmeyebilir. Sunucu için tutarlı bir başlangıç sunulup istemci hazır olduğunda uygun güncelleme yapılabilir. Yerleşimi yalnız JavaScript ölçümüyle değiştirmek yerine CSS’in yapabileceği işlere CSS’i bırakmak da bazı gereksiz farkları önler.
JavaScript kapalıyken içerik kaybolmalı mı?
Okunacak makale, ürün açıklaması veya normal bağlantı gibi temel içerik için buna çoğu zaman gerek yoktur. Sunucuda üretilmiş içerik erişilebilir kalabilir, özel araçlar ise destek durumunu açıklayabilir. Bir filtre gelişmiş davranışını kaybetse bile bütün listeye erişim sağlanabilir. Bu yaklaşım yalnız JavaScript kapalı kullanımına değil, kodun geç yüklendiği veya başarısız olduğu durumlara da daha dayanıklı bir deneyim sunar.
İlk ekrandaki farklılığı bul.
Saat, dil tercihi ve açılır menü içeren küçük bir sayfa düşün. Sunucunun ve tarayıcının ilk çıktısını ayrı listeler halinde tarif et. Her farklılığın nereden geldiğini ve kullanıcıya ne zaman gösterilmesi gerektiğini belirle. Amaç uyarıyı gizlemek değil, başlangıç sözleşmesini kurmak.
Hydration, hazır görünen ekranın yaşayan davranışa geçişidir. İyi bir başlangıç sözleşmesi ve dar etkileşim sınırları, bu geçişin kullanıcıya bir aksama olarak yansımamasına yardımcı olur.
Bağlantılı kavramlar
- SSGSSG, sayfa içeriğinin kullanıcı isteğinden önce oluşturulup hazır HTML olarak sunulması yaklaşımıdır.
- SSRSSR, bir sayfanın HTML içeriğinin istek sırasında sunucuda oluşturulması yaklaşımıdır.
- INPINP, bir sayfanın kullanıcı etkileşimlerine görsel yanıt verme gecikmesini değerlendiren etkileşim metriğidir.

