deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

Fitz'e izomorfik hydration geliyor: sunucu HTML'i çiziyor, bir WASM runtime DOM'u sahipleniyor

Fitz'in yeni opt-in hydration özelliğinde sunucu bir bileşeni HTML olarak render ediyor, derlenmiş WASM istemcisi ise aynı DOM düğümlerini sahiplenerek reconciliation gerektirmeden ve bir framework runtime'ı göndermeden state'i geri yüklüyor.

Fitz'e izomorfik hydration geliyor: sunucu HTML'i çiziyor, bir WASM runtime DOM'u sahipleniyor

Sahiplenme, reconciliation yerine

Martin Palopoli'nin dev.to'daki FitzLiveViews serisinin sekizinci bölümü, Fitz framework'ünde yeni bir hydration yolunu ele alıyor: tek bir .fitzv bileşeni artık hızlı bir ilk boyama için sunucuda HTML olarak render edilebiliyor ve ardından o DOM, olduğu gibi derlenmiş bir WebAssembly istemcisine devrediliyor. WASM runtime, sayfayı yeniden inşa etmek ya da sanal bir DOM'u sunucu çıktısıyla karşılaştırmak yerine mevcut düğümleri sahipleniyor — onları gezerek serialize edilmiş state'i geri yüklüyor ve event listener'ları yerinde bağlıyor.

Özellik opt-in. Bir bileşen bildirimine hydrate işareti eklemek, bileşenin iki derlenmiş çıktısını — sunucu HTML'i ve bağımsız bir WASM uygulaması — iş birliği yapmaya hazırlıyor. Palopoli, işaretin bilinçli olarak isteğe bağlı olduğunu belirtiyor; böylece Fitz'in LiveViews WebSocket devralması için render edilen, DOM diffing'i kök içinde script etiketine izin vermeyen bileşenleri, öncekiyle bayt bayt aynı kalıyor.

Sunucu ne gönderiyor

Gönderiye göre SSR emitter, elle yazılmış bir kabuğa bel bağlamak yerine bileşenin gerçek bir render-to-string işlemini gerçekleştiriyor. Render edilen HTML'in yanı sıra, bileşene anahtarlanmış, state'ini taşıyan bir JSON script payload'ı gömüyor; böylece istemci şablon varsayılanları yerine sunucunun değerleriyle başlıyor.

Sunucu ayrıca istemcinin gezinebileceği sahiplenme işaretleri bırakıyor: metin interpolation'larının ve {#if} ile {#for} bölgelerinin etrafına eşleşen HTML yorumları, birleştirilmiş alt bileşenlerin etrafına bir wrapper div ve parent'ın kapsamına inline edilen slot içeriği.

İstemci açılışta ne yapıyor

Hydration'a uygun bileşenler mount() yerine hydrate() çalıştırıyor. Runtime, mount kökünde zaten içerik olduğunu görüyor, serialize edilmiş state'i geri yüklüyor — primitive'lerin yanı sıra listeler, string anahtarlı map'ler, nullable'lar ve JSON üzerinden gidiş-dönüş yapan import edilmiş nominal tipler gibi bileşik yapılar — ardından mevcut DOM'u bir imleçle derinlik öncelikli gezerek her element, metin ve yorum düğümünü, taze bir inşanın oluşturacağı aynı iç handle'lara eşliyor. Ne create_element var, ne kökün silinmesi. Event listener'lar daha sonra sahiplenilen düğümlere bağlanıyor.

O andan itibaren state değişiklikleri keep-node reconciliation ile yerinde yamanıyor; Palopoli bunun, sayfa hiçbir zaman yeniden inşa edilmediği için odaklanmış bir input'un imlecini bozulmadan koruduğunu söylüyor.

Akış, Puppeteer aracılığıyla gerçek Chrome'da uçtan uca doğrulandı; bunlara, başlatmadan önce sunucuda çizilmiş bir düğüm üzerinde bir JavaScript özelliği ayarlayan bir test de dahil: özellik hydration'dan sonra da varlığını sürdürüyor ve bu da düğümün yeniden oluşturulmak yerine sahiplenildiğini gösteriyor. Dört çalıştırılabilir örnek, temel durumu, karışık statik ve interpolation'lı metni, koşullu ve liste bölgelerini ile alt bileşenler ve slot'larla birleştirmeyi kapsıyor.

React, Astro ve LiveView karşısındaki konumu

Gönderi, hydration'ın JavaScript dünyasında büyük ölçüde çözülmüş bir sorun olduğunu açıkça kabul ediyor; savunusu maliyetle ilgili. React ve Next.js framework runtime'ını istemciye gönderiyor ve sunucu HTML'ine karşı bir reconciliation geçişi çalıştırıyor; ikisi arasındaki uyuşmazlıklar bütünüyle ayrı bir uyarı kategorisi doğuruyor. Astro'nun island'ları ve partial hydration'ı gönderileni azaltıyor, ancak her island yine de bir JavaScript framework runtime'ı gömülü taşıyor. Phoenix LiveView ve Hotwire istemciyi, DOM'u sunucu adına yaman ince bir JS katmanı olarak tutarken, Fitz'in istemcisi kendi state'i olan, boş bir mount yerine tam olarak sunucunun DOM'uyla başlayan tam derlenmiş bir uygulama.

Öne çıkan fark iddiası bu kombinasyon: her iki uç için tek kaynak dosya, düğüm düğümüne sahiplenme, bileşen başına opt-in seçim, sonrasında keep-node yamalama ve hat üzerinden framework runtime'ı gönderilmemesi.

MVP'nin bilinen sınırları

Palopoli dürüstçe sınırları da sıralıyor. Hydration bileşen başına opt-in; evrensel otomatik hydration gelecek iş olarak işaretlenmiş. Bileşik state doğru geri yükleniyor, ancak bir JSON gidiş-dönüşünden kurtulamayan tipler — string olmayan anahtarlı bir map, tuple'lar, fonksiyonlar — geri yüklemede varsayılanlarına sıfırlanıyor. SSR emitter'da adlandırılmış slot'lar ile koşullu veya liste bölgelerindeki dinamik birleştirme sonraki dilimlere ertelenmiş durumda; varsayılan slot ve statik birleştirme bugün çalışıyor. Serinin bir sonraki bölümü, gerçek bir admin uygulamasından çıkarılmış yaklaşık 40 import edilebilir bileşenlik bir eşlik eden UI kütüphanesini ele alacak.

Neden önemli

Web geliştiricileri için buradaki ilginç fikir, sunucuda render edilen HTML ile istemci etkileşimi arasındaki düğümü kesmek. Tek kaynak her iki ucu da üretiyor ve devir işlemi DOM kimliğini tamamen koruyor: yeniden render parlaması yok, hydration uyuşmazlığı uyarısı yok ve tarayıcıya gönderilen bir framework runtime yok. Fitz, yazarının bunu Next.js'e hazır bir rakip değil bir MVP olarak çerçevelediği genç bir proje olmaya devam ediyor; ancak WASM runtime tarafından yönlendirilen sahiplenme temelli hydration, frontend mantığını JavaScript'ten tamamen taşıma konusundaki daha geniş tartışmaya somut bir veri noktası.

  • #fitz
  • #webassembly
  • #hydration
  • #server-side-rendering
  • #frontend

İlgili yazılar