Ciao, e benvenuto nella quarta puntata della settantottesima stagione. La volta scorsa, il divario tra sembrare giusta e funzionare giusta, e il nome del ponte: l'idratazione. Oggi vediamo cosa fa davvero, perché è il cuore di tutta la macchina, ed è la parola più fraintesa del web moderno. Il titolo: dare vita al piatto.
Partiamo dall'idea ingenua, e dal perché è sbagliata. Verrebbe da pensare che l'idratazione prenda l'HTML del server e, cosa, ci appiccichi sopra qualche gestore di clic? Magari. La sottigliezza è che il client non può limitarsi a spolverare il comportamento sopra: deve ricostruire la propria comprensione completa della pagina, per sapere dove va ogni pezzo di comportamento.
Vediamo cosa fa davvero, passo per passo. Quando le istruzioni arrivano, il client fa tre cose. Primo: ri-esegue i tuoi componenti, lo stesso codice che aveva eseguito il server, adesso nel browser, producendo una propria idea di come dovrebbe essere la pagina. In pratica ri-cucina il piatto, nella sua testa. Secondo: percorre l'HTML già arrivato dal server, il piatto già impiattato e già dipinto, e lo fa combaciare con quell'idea, nodo per nodo. Questo bottone nell'HTML è il bottone che il mio componente dice debba stare qui. Terzo: lo adotta. Invece di buttare via l'HTML del server e costruire da capo, tiene il corpo che c'è già e gli attacca sopra il comportamento, i gestori degli eventi, lo stato, la reattività, sui nodi che sono già lì. Quindi l'idratazione è questo: ri-ricava la pagina nel client, poi adotta il corpo già arrivato dal server come sua incarnazione, cablandoci la vita senza ridisegnare il corpo. La sala non ri-cucina il piatto: riconosce quello impiattato come quello che avrebbe fatto lei, e gli mette sopra il servizio.
Perché tutta questa fatica di combaciare e adottare, invece di far costruire al client la pagina da zero come nel rendering al tavolo puro? Perché il server l'ha già dipinta, ed è sullo schermo. Se il client la demolisse e la ricostruisse, chi guarda vedrebbe un lampo: la pagina completa che sparisce e si ridisegna, e avremmo buttato via proprio il primo sguardo veloce che era il motivo di tutto. Se la buttassimo e la rifacessimo, il rendering del server non sarebbe servito a niente. Il compito dell'idratazione è prendere in carico la pagina esistente in modo invisibile, così che chi guarda non si accorga mai dell'istante in cui è arrivato il servizio. Fatta bene, non c'è nessuno sfarfallio: un attimo il piatto è inerte, l'attimo dopo risponde, e sembrava identico per tutto il tempo. È l'adozione a rendere il passaggio di mano senza cuciture.
E qui il requisito decisivo: i due devono combaciare. Perché l'adozione funzioni, l'idea che il client si fa della pagina deve combaciare con l'HTML del server, da vicino. La sala può mettere il servizio in modo pulito solo su un piatto impiattato come se lo aspetta. Se il server ha cucinato una cosa e i componenti del client ne cucinerebbero un'altra, l'adozione si rompe: il metodo trova un bottone dove si aspettava del testo, e deve arrangiarsi. È per questo che lo stesso codice dei componenti, con gli stessi dati, deve girare in entrambi i posti: il combaciare dipende dal loro andare d'accordo. Le conseguenze piene, l'errore di mancata combaciata e il doppio costo, sono la prossima puntata.
E nota la verità silenziosa, quella che lega al ritornello. Guarda cosa è appena successo: la pagina è stata resa due volte. Una sul server, per produrre l'HTML che hai visto. Una nel client, per capire cosa adottare. L'idratazione è, per sua natura, un secondo rendering, non di pixel, ma della logica dei componenti, steso sopra il primo. Non è un difetto o un'inefficienza da correggere: è ciò che l'idratazione è. Il rendering del server ti compra il primo sguardo veloce; il rendering del client ti compra l'interattività; e l'idratazione è la stretta di mano tra i due, che per forza vuol dire fare il ragionamento due volte.
Voglio lasciarti con cosa è davvero l'idratazione, perché quasi tutti la fraintendono. Non è aggiungere qualche gestore di clic a un HTML morto. È ri-eseguire i tuoi componenti nel browser per ricostruire l'idea della pagina, poi riconoscere l'HTML già arrivato dal server come l'incarnazione di quell'idea, e attaccarci sopra la vita senza ridisegnare il corpo. È un'adozione, non una ricostruzione, ed è apposta invisibile, perché chi guarda non deve accorgersi dell'istante in cui il piatto, da inerte, diventa vivo. Tieni questa immagine: la sala non ri-cucina il piatto, lo riconosce come il proprio e gli dà servizio. E tieni anche il seme del prossimo discorso: per riconoscerlo, deve prima ri-pensarlo. La pagina viene pensata due volte.
Per oggi ci fermiamo qui. Abbiamo visto cosa fa davvero l'idratazione: ri-eseguire i componenti nel client, far combaciare l'idea con l'HTML del server, e adottare il corpo esistente attaccandogli la vita; perché si adotta invece di ricostruire, cioè per evitare lo sfarfallio e rendere il passaggio invisibile; e il requisito che i due combacino, da cui dipende tutto. Sotto a tutto, la pagina pensata due volte. Nella prossima puntata: hai pagato due volte. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.