Guide

Il rendering lato server consegna un HTML già completo prima che venga eseguito un solo byte di JavaScript, ed è per questo che aiuta il primo disegno della pagina e i crawler. Ma quell'HTML è inerte. La documentazione di Vue lo dice senza giri di parole: se fai clic sul pulsante, il numero non cambia, perché la pagina resta statica finché il framework non prende il controllo nel browser. L'hydration è proprio quel passaggio di consegne.

Vue descrive il meccanismo con precisione. Durante l'hydration crea la stessa applicazione Vue eseguita sul server, associa ogni componente ai nodi del DOM che deve controllare e collega i listener di eventi del DOM. Quando tutto va bene non si ricostruisce nulla da zero: il markup è già lì e l'hydration se ne appropria.

Va richiesta esplicitamente, non avviene da sola. Montare nel client un'applicazione renderizzata dal server richiede createSSRApp e non createApp, perché è così che si dice a Vue che l'HTML era pre-renderizzato e che deve idratarlo invece di montare nuovi nodi DOM. Sbagliare funzione è un modo comune per renderizzare tutto due volte senza accorgersene.

Quando le due versioni divergono

Tutto questo presuppone che l'output del server e le attese del client coincidano. Quando non coincidono si ottiene un mismatch di hydration, che Vue definisce come la struttura DOM dell'HTML pre-renderizzato che non corrisponde all'output atteso dall'applicazione lato client.

La documentazione indica tre cause, e nessuna è esotica.

Le tre cause documentate

La prima è l'annidamento HTML non valido. Se un template mette un div dentro un p, è il parser del browser stesso a correggere la struttura mentre legge l'HTML del server, e il DOM così corretto non corrisponde più a ciò che si aspetta il client. Il framework non ha sbagliato nulla: è il browser ad aver riscritto la pagina prima ancora che Vue la vedesse.

• L'hydration ricrea nel browser l'applicazione eseguita sul server, associa i componenti ai nodi DOM esistenti e collega i listener di eventi.
• Richiede createSSRApp anziché createApp, il che dice a Vue di idratare invece di montare nodi nuovi.
• Un mismatch di hydration si verifica quando il DOM pre-renderizzato non corrisponde a ciò che si aspetta l'applicazione lato client.
• Vue indica tre cause: annidamento HTML non valido corretto dal parser del browser, valori generati casualmente e fusi orari diversi tra server e client.
• Vue recupera automaticamente e l'applicazione continua a funzionare, ma i nodi scartati e rimontati costano in prestazioni di rendering.

La seconda sono i valori generati casualmente. La stessa applicazione viene eseguita due volte, una sul server e una nel browser, e nulla garantisce che un valore casuale sia identico tra le due esecuzioni. Tutto ciò che viene estratto al momento del render finirà per divergere.

La terza sono i fusi orari. Quando server e client si trovano in fusi diversi, una data formattata durante l'esecuzione sul server e la stessa data formattata nel browser non coincideranno. È la causa che sopravvive più a lungo in produzione, perché si manifesta solo per gli utenti che stanno nel posto sbagliato.

Perche e un costo silenzioso

Quello che succede dopo spiega perché questo bug sia così facile da ignorare. Vue tenta di recuperare automaticamente e adatta il DOM pre-renderizzato allo stato del client, così l'applicazione in genere continua a funzionare. Il prezzo è una perdita di prestazioni di rendering, perché i nodi errati vengono scartati e al loro posto ne vengono montati di nuovi.

Un mismatch quindi è raramente un crash. È una tassa silenziosa: il server ha prodotto HTML, poi una parte di quel lavoro è stata buttata via e rifatta nel browser. Hai pagato il rendering lato server due volte e ne hai tenuto il beneficio una sola. È esattamente il tipo di regressione che un test funzionale non intercetta mai, perché la pagina continua ad apparire corretta.

La risposta piu semplice per le pagine statiche

Se i dati necessari a renderizzare una pagina sono gli stessi per tutti gli utenti, Vue indica una risposta più semplice del rendering a ogni richiesta: la generazione di siti statici, chiamata anche pre-rendering, in cui la pagina viene renderizzata una volta sola durante la build. L'hydration si applica comunque al risultato, ma il costo server per ogni richiesta sparisce. Prima di ottimizzare una pipeline SSR, vale la pena chiedersi se la pagina dovesse davvero essere dinamica.