Router dell'app Next.js: la guida al Thinking Server per impostazione predefinita

Quando Next.js ha lanciato l'App Router, ha fatto qualcosa che sembra tecnico ma che, in sostanza, è una decisione mentale: ha invertito lo schema. Prima, ogni componente era di proprietà del cliente finché non dicevi diversamente. Ora, ogni componente è lato server finché non controlli che debba essere lato client.

Questa inversione è piccola nella sintassi ma enorme nella pratica. Cambia la domanda che il team pone a ciascun componente. Invece di dare per scontato che tutto venga eseguito nel browser, giustifichi il motivo per cui qualcosa dovrebbe essere eseguito lì.

Per chi proviene da React tradizionale, l'App Router non è solo una nuova cartella con un router diverso. È un invito a ripensare dove dovrebbe vivere ogni parte dell'applicazione. E questo invito tende a disorientare prima ancora di avere senso.

Lo schema si è invertito

In App Router, i layout e le pagine sono componenti server per impostazione predefinita. Ciò significa che, quando crei una nuova pagina, questa inizia a funzionare sul server, senza che tu faccia nulla. Il suo codice non va al browser e la ricerca dei dati può avvenire proprio lì, prima che venga inviata la risposta.

La conseguenza immediata è che molte cose che vorresti inviare al client ora rimangono naturalmente sul server. L'elenco dei prodotti, il contenuto dell'articolo, l'intestazione con i dati dell'utente, tutto questo viene renderizzato prima di arrivare, senza alcun costo JavaScript sul dispositivo.

Quando hai bisogno di interattività, contrassegni il componente con la direttiva "use client". Da quel momento in poi, quel componente e ciò che ne rappresenta iniziano a essere eseguiti nel browser, con stato ed eventi. È un confine esplicito, non un incidente.

L’effetto collaterale salutare è che il cliente diventa un’eccezione consapevole. Non ci cadi per inerzia, scegli tu quando entrarci. Se questo sembra ancora astratto, vale la pena rivedere cosa sono i componenti React Server](/post/o-que-sao-react-server-components) prima di andare avanti.

Quando il componente deve essere server

La domanda giusta riguarda la natura del lavoro. Se il componente si limita a cercare e visualizzare informazioni, ha tutto per essere un server. Pagine di elenchi, contenuti di blog, dettagli di ordini, dashboard che mostrano solo numeri: niente di tutto ciò ha bisogno che il browser esista.

I componenti del server eccellono nel recupero dei dati. Consulti direttamente la banca, chiami i servizi interni con la bassa latenza di quelli interni all'infrastruttura e crei il risultato pronto. Non è necessaria una via API intermedia solo affinché il browser possa richiedere i dati, perché il componente è già sul lato destro.

C'è anche il vantaggio di mantenere il peso lontano dal cliente. Librerie di formattazione pesante, elaborazione di markdown, manipolazione di dati: se viene eseguito sul server, non entra mai nel pacchetto scaricato dall'utente. Il bundle si restringe e il dispositivo dell'utente ringrazia.

La regola mentale che funziona è questa: inizia prendendo il controllo del server. Rivolgersi al cliente solo quando c'è una concreta necessità di interazione. Resistere alla tentazione di marchiare tutto come cliente è metà dell'opera.

Quando il componente deve essere lato client

Non tutto si adatta al server e provare a forzare questo porta alla frustrazione. Esiste un insieme chiaro di situazioni che richiedono clienti, e riconoscerle rapidamente evita perdite di tempo.

Il primo è lo stato che cambia sullo schermo. Un contatore, una scheda selezionata, un menu che si apre e si chiude: tutto ciò che ha bisogno di ricordare qualcosa tra le interazioni vive nel client. Il secondo è l'evento utente. Facendo clic, digitando, trascinando, qualsiasi manipolazione diretta avviene nel browser, perché è lì che si trova l'utente.

Il terzo è l'utilizzo delle risorse del browser. L'accesso all'archiviazione locale, alla geolocalizzazione, alla dimensione della finestra di lettura, tutto ciò che esiste solo nell'ambiente del browser richiede che il componente sia lato client. Non c'è modo di eseguirlo sul server, semplicemente perché il server non ha finestre o mouse.

Il dettaglio che sblocca la mente della squadra è capire che non è tutto o niente. Puoi avere una pagina server che esegue il rendering di un piccolo componente client solo per il pulsante interattivo. Il resto della pagina rimane leggero e renderizzato sul server. L'interattività viene isolata dove conta davvero, invece di contaminare l'intera pagina.

La ricerca dei dati cambia posizione

Nel vecchio modello, il recupero dei dati era un rituale ben noto: il componente si assemblava, attivava un effetto, chiamato API, si occupava del caricamento e degli stati di errore e aggiornava lo stato quando arrivava la risposta. Ha funzionato, ma era prolisso e pieno di insidie.

Con i componenti server, il recupero dei dati diventa nuovamente semplice. Recuperi i dati durante il rendering sul server, attendi il risultato proprio lì e restituisci l'interfaccia già pronta. Aggiungi molta danza degli stati di caricamento al client, perché i dati arrivano già con la pagina.

Ciò semplifica il codice e allo stesso tempo migliora l'esperienza, cosa rara. L'utente riceve il contenuto già compilato, senza che quella sequenza di schermate vuote lampeggi durante il caricamento di ciascuna parte. E quando è necessario un caricamento progressivo, il framework offre lo streaming per fornire i blocchi non appena sono pronti, un argomento che vale la pena approfondire caching e streaming in Next.js.

La mutazione dei dati segue una logica simile. Invece di mettere insieme un'API completa per ogni modulo, puoi utilizzare le Server Actions, funzioni che vengono eseguite sul server e vengono chiamate direttamente dall'interfaccia. Questo chiude il ciclo: leggere e scrivere vicino alla fonte, senza strati che esistevano solo per servire il browser.

Il cambio di mentalità che la squadra deve affrontare

La parte difficile di App Router non è la sintassi. È disimparare il riflesso che tutto gira nel browser. I team esperti in React tendono a contrassegnare i componenti come client per abitudine, perché è così che hanno imparato, e quindi perdono gran parte del guadagno.

Il sintomo classico è il simbolo "use client" all'inizio di quasi tutti i file. Quando ciò accade, l’applicazione torna ad essere una SPA sotto mentite spoglie, con in più il peso di prima e la nuova complessità. Il team deve interiorizzare che ogni appuntamento con un cliente è una decisione da giustificare, non uno schema da copiare.

C'è anche un aggiustamento mentale su dove viene eseguito il codice. Pensare che parte dell'albero venga eseguito sul server e parte sul browser richiede attenzione a ciò che ciascuna parte può fare. Tentare di utilizzare una funzionalità del browser in un componente server genera errori e questi inciampi iniziali sono una parte normale dell'apprendimento.

Una volta che il centesimo scende, il modello diventa intuitivo. La domanda è se è necessario che l'interazione diventi automatica e il team inizia a progettare interfacce leggere per impostazione predefinita. Ma per arrivarci è necessaria una leadership tecnica disposta a rivedere pazientemente il codice e a correggere i vecchi riflessi.