Rozdíl není v hydrataci, ale v tom, co je výchozí
Klasická SPA i klasická SSR aplikace sdílejí jeden nevyslovený předpoklad: celá stránka je jedna aplikace. Server sice pošle HTML, ale to HTML je jen obrázek toho, jak bude aplikace vypadat, až se na klientovi rozběhne. Aby fungovalo cokoli, musí se stáhnout a spustit všechno, nasadit se na kořen stromu a proiterovat celý strom dolů.
Islands architecture — termín, který podle Jasona Millera vymyslela Katie Sylor-Miller z Etsy v roce 2019 — ten předpoklad obrací. Stránka je statický HTML dokument, který obsahuje několik samostatných vložených aplikací. Ne aplikace, která mimochodem umí vyrenderovat HTML.
Mechanismus: díry vyříznuté do statické stránky
Postup je konkrétní. Vyrenderuješ stránku na serveru a kolem výrazně dynamických oblastí vložíš zástupné sloty. Každý slot obsahuje serverem vyrenderovaný HTML výstup svého widgetu. Pak se každý ostrov hydratuje nezávisle, znovupoužije svoje serverové HTML a stane se interaktivním sám za sebe.
Klíčové slovo je nezávisle, a je to víc než jen slovo o výkonu. V progressive hydration pořád platí, že existují kořenové komponenty, které se musí inicializovat dřív než jejich potomci. Strom má vrchol a ten vrchol je společný. U ostrovů žádný takový vrchol není. Ostrov nezná ostatní ostrovy, nemá společného rodiče, se kterým by musel čekat, a nemá pořadí. Jednotlivé oblasti stránky se stanou interaktivními, aniž by se předtím muselo načíst cokoli jiného.
Z toho plyne i to, co ostrovy nedělají. Neopakuje se u nich vzor, kdy první render zničí serverem vyrenderovaný DOM, aby ho hned postavil znovu od nuly. Ostrov staví na tom, co už v dokumentu je.
Proč je to jiná věc než progressive enhancement
Progressive enhancement dělá povrchně totéž: statické HTML, do kterého se dodatečně zavěsí chování. Rozdíl je v tom, co dostaneš navíc.
Ostrovy přidávají dvě věci. Za prvé SSR hydrataci — server a klient renderují stejnou komponentu ze stejného kódu, takže se výstupy nemusí udržovat ručně v synchronizaci ve dvou jazycích. Za druhé konzistentní metaforu pro přidání interaktivity k oblasti stránky. Progressive enhancement je technika, kterou aplikuješ případ od případu. Ostrov je jednotka, kterou má framework v ruce a může s ní systematicky pracovat — určit, kdy se má načíst, jestli až ve viewportu, jestli až po interakci.
Ta druhá věc je důvod, proč z toho vznikla architektura a ne jen rada.
Co za to platíš
Cena není v runtime, ale v návrhu. Když je stránka jedna aplikace, sdílený stav je zadarmo — komponenty jsou ve stejném stromě, takže context, store nebo prop projdou. Mezi ostrovy nic takového neexistuje. Dva ostrovy, které si potřebují říct, že se změnil obsah košíku, spolu musí komunikovat přes něco vně obou: událost na window, URL, storage, nebo server.
To tlačí na rozhodnutí, které v SPA nikdy nemusíš udělat: kde přesně vedeš hranice ostrovů. Když jich uděláš moc a jsou malé, vyrobíš si síť postranních kanálů. Když uděláš jeden velký, aby v něm sdílený stav fungoval, jsi zpátky u hydratace celé stránky a nic jsi nezískal. Hranice ostrova je tím architektonickým rozhodnutím, ne konfigurací.
Praktické vodítko: veď hranici tam, kde jde dat i stavu přes ni málo. Ostrov je dobrý, když si vystačí se svým vlastním stavem a serverem. Špatný, když se každou chvíli potřebuje ptát souseda.
Co si z toho odnést
Ostrovy nejsou technika, jak zlevnit hydrataci. Jsou to volba defaultu. V SPA je interaktivní všechno a ty se snažíš odečítat; u ostrovů je interaktivní nic a ty přičítáš vědomě, kus po kuse. Ta změna znaménka je celý vtip a všechny výkonové výhody jsou její důsledek, ne cíl.
Když stavíš stránku, kde je většina obsahu ke čtení a interaktivita sedí v pár ohraničených místech — obsahový web, dokumentace, e-shop mimo checkout — jsou ostrovy správnou výchozí volbou. Když se naopak většina plochy mění podle sdíleného stavu, hranice ostrovů se ti rozpadnou a jednotná aplikace je poctivější odpověď. Rozhodni to podle toho, kolik stavu teče přes hranice, ne podle toho, jak rychle se nabízí první vykreslení.