Renderowane po stronie serwera SPA z Turbolinks 5

W wyborach frontu jest fałszywa dychotomia: albo tradycyjna aplikacja wielostronicowa z pełnymi przeładowaniami przy każdym kliknięciu, albo pełna aplikacja jednostronicowa w React z całą maszynerią, którą to pociąga. Turbolinks 5 — znacząco przepisany względem wcześniejszych wersji — wytycza trzecią pozycję, a w połączeniu ze Stimulusem daje ci większość odczucia SPA, pozostając renderowaną po stronie serwera aplikacją Rails. To podejście „HTML over the wire” jest po cichu właściwym domyślnym wyborem dla dużej klasy aplikacji i warto zrozumieć je porządnie.

Co robi Turbolinks 5

Turbolinks przechwytuje kliknięcia linków i wysłania formularzy, pobiera nową stronę przez sieć w tle i podmienia <body> — zastępując zawartość strony bez pełnego przeładowania przeglądarki. Ponieważ przeglądarka nigdy nie rozbiera i nie buduje od nowa środowiska JavaScript, nigdy nie parsuje ponownie CSS i JS, nawigacja czuje się niemal natychmiastowa. Dodaj jego cache, a doświadczenie robi się jeszcze szybsze:

<!-- Turbolinks jest w dużej mierze przezroczysty — linki po prostu działają, szybciej -->
<a href="/products/42">Zobacz produkt</a>

Przepisanie wersji 5 uczyniło go bardziej odpornym niż oryginał (który omawialiśmy ostrożnie w czasach Rails 4) i co kluczowe dostarcza prawdziwy cache oraz pasek postępu: Turbolinks trzyma cache niedawno odwiedzonych stron i pokazuje cache’owaną wersję natychmiast przy nawigacji, pobierając świeżą w tle, potem ją podmienia. Nawigacja wstecz/naprzód jest natychmiastowa. Efektem jest to, że zwykła renderowana po stronie serwera aplikacja nawiguje z responsywnością, którą ludzie kojarzą z SPA — za darmo, bez routera po stronie klienta, bez API, bez stanu klienta do zarządzania.

Haczyk i jak rozwiązuje go Stimulus

Historycznym zarzutem wobec Turbolinks był dokładnie ten, który podnieśliśmy lata temu: ponieważ strona nigdy się w pełni nie przeładowuje, $(document).ready odpala się raz, a twój JavaScript przestaje się reinicjalizować przy nawigacji. Ten zarzut jest teraz odpowiedziany, a odpowiedzią jest Stimulus. Kontrolery Stimulusa doczepiają się automatycznie do pasującego markupu, ilekroć się pojawia — w tym nowego <body>, które Turbolinks podmienia — i rozbierają się, gdy znika. Oba są zaprojektowane, by działać razem:

<div data-controller="dropdown">
  <button data-action="dropdown#toggle">Menu</button>
  <div data-dropdown-target="menu" hidden>...</div>
</div>

Gdy Turbolinks podmienia stronę zawierającą ten markup, Stimulus instancjuje kontroler dropdown automatycznie; gdy nawigujesz dalej, rozłącza go. Problem „moje handlery umarły po pierwszej stronie”, który czynił wczesny Turbolinks bolesnym, po prostu nie istnieje ze Stimulusem, bo cały model Stimulusa to „zachowanie doczepione do markupu, gdziekolwiek i kiedykolwiek ten markup się pojawia”. Razem są kompletnym pakietem: Turbolinks do szybkiej nawigacji, Stimulus do interaktywności — oba nad renderowanym po stronie serwera HTML.

Architektura i dlaczego jest atrakcyjna

Cofnij się i spójrz, co to daje w porównaniu z SPA:

Serwer renderuje HTML; nie ma API do zbudowania. Twoje kontrolery i widoki Rails produkują HTML, jak zawsze. Nie utrzymujesz osobnego API JSON i aplikacji klienta, która je konsumuje — masz jedną aplikację.
Brak zarządzania stanem po stronie klienta. DOM i serwer są stanem. Nie ma store’a Redux do trzymania w synchronizacji, brak duplikacji logiki klient/serwer, brak unieważniania cache między dwoma reprezentacjami tych samych danych.
SEO i pierwsze malowanie za darmo. Renderowany po stronie serwera HTML jest w pełni indeksowalny i maluje się szybko przy pierwszym załadowaniu — żadnej gimnastyki SSR, której SPA React potrzebuje, by być przyjaznym SEO.
Używasz frameworka, który znasz. To po prostu Rails, z dwiema małymi bibliotekami JavaScript nałożonymi na wierzch. Cały zespół może w tym pracować bez uczenia się osobnego stosu frontu.

Dla dużej klasy aplikacji będących w większości renderowaną po stronie serwera treścią i formularzami z potrzebą szybkiej nawigacji i trochę interaktywności — czyli większości aplikacji CRUD i handlu — to naprawdę lepszy handel niż SPA: dostajesz większość responsywności za ułamek złożoności.

Gdzie się zatrzymuje

Uczciwość, jak zawsze. To podejście daje ci nawigację i interaktywność w stylu SPA, ale to nie SPA, i są rzeczy, których nie robi. Naprawdę aplikacyjne doświadczenia ze złożonym, długowiecznym stanem klienta, który nie mapuje się na DOM — edytor współpracy, narzędzie do rysowania, dashboard na żywo z wieloma niezależnie aktualizującymi się widżetami — wciąż chcą prawdziwego frameworka klienta. A choć Turbolinks + Stimulus obsługuje nawigację i dyskretne interakcje pięknie, częściowe aktualizacje strony (zastąpienie tylko jednego fragmentu w odpowiedzi na akcję, bez pełnej nawigacji) są wciąż trochę ręczne w 2019 — sięgasz po żądanie Ajax i trochę Stimulusa, by podmienić zawartość. To dokładnie ta luka, którą następna ewolucja tej idei zmierza domknąć.

Dokąd to zmierza

Warto widzieć Turbolinks + Stimulus jako kierunek, nie punkt końcowy. Filozofia „HTML over the wire” — serwer renderuje HTML, drut niesie HTML (nie JSON), JavaScript pozostaje skromny — zbiera realny rozpęd jako świadoma alternatywa dla założenia SPA-domyślnie. Oczywistym następnym krokiem jest uczynienie częściowych aktualizacji tak łatwymi, jak pełnostronicowa nawigacja już jest — wysyłanie fragmentów HTML przez drut, by aktualizować kawałki strony, i pchanie ich z serwera w czasie rzeczywistym. Ta ewolucja wyraźnie nadchodzi, a nauczenie się budowania w ten sposób teraz — renderowany po stronie serwera HTML, Turbolinks do nawigacji, Stimulus do zachowania — pozycjonuje cię wprost pod nią.

Werdykt

Turbolinks 5 plus Stimulus rozpuszcza fałszywy wybór między toporną aplikacją wielostronicową a złożonym SPA. Dostajesz szybką, cache’owaną nawigację i czystą, odporną interaktywność nad zwykłym renderowanym po stronie serwera HTML — bez API, bez store’a stanu klienta, bez gimnastyki SEO, bez osobnej aplikacji frontu — używając Rails, który już znasz. To nie dla każdej aplikacji: naprawdę aplikacyjne fronty z bogatym stanem klienta wciąż chcą Reacta. Ale dla dużego środka — aplikacji treści-i-formularzy, które chcą czuć się szybko i nowocześnie — to lepszy domyślny wybór niż branżowy SPA-odruchowo, i siedzi wprost na ścieżce, którą framework zmierza. Buduj w ten sposób, a dostajesz większość doświadczenia SPA za mały ułamek kosztu.