El mòdul anterior va acabar assenyalant una frontera: CicloUrbano és una aplicació que es descarrega al navegador i s'hi executa. Aquesta decisió, que al mòdul 1 semblava purament tècnica, té conseqüències que no s'arreglen amb memo, ni amb divisió de codi, ni amb proves. El primer pintat espera el JavaScript; els cercadors i les xarxes socials veuen una pàgina buida; i en una connexió lenta l'usuari mira un fons blanc durant segons. Aquesta lliçó travessa aquesta frontera. Entendràs què fa exactament el navegador quan rep una aplicació d'una sola pàgina, quines són les quatre estratègies de renderitzat que existeixen i quan convé cadascuna, què és la hidratació i per què és el punt on el SSR es trenca, i com es construeix tot això amb Next.js 15 i el seu App Router. Al final tindràs en marxa ciclourbano-web, l'aparador públic de CicloUrbano renderitzat al servidor, convivint amb l'aplicació de gestió que portes nou mòduls construint.

1. El que rep avui el navegador: un <div> buit
2. Què implica per al primer pintat i per a les connexions lentes
3. El que veuen els cercadors i les targetes de previsualització
4. Les quatre estratègies de renderitzat
5. Què és la hidratació
6. Discrepàncies entre servidor i client
7. Per què cal un framework
8. Next.js 15: crear ciclourbano-web
9. Rutes per carpetes: layout, page, loading, error, not-found
10. Del mapa de React Router al mapa de Next.js
11. Components de servidor: dades amb async/await
12. La directiva 'use client', en quatre línies
13. Renderitzat dinàmic: quan Next.js decideix renderitzar a cada petició
14. Metadades i SEO
15. Sessió sense localStorage
16. Streaming: l'HTML per parts

Obre l'index.html del projecte Vite de CicloUrbano i mira què s'envia realment al navegador. No és el que veus en pantalla: és això.

Aquest és tot l'HTML de CicloUrbano. Un contenidor buit i una etiqueta <script>. Tota la resta —la capçalera, el catàleg, les cinc targetes de bicicleta, el peu de pàgina— la construeix JavaScript al navegador després.

Ho pots comprovar tu mateix sense eines especials. Al navegador, «Mostra el codi font de la pàgina» (Ctrl+U) mostra l'HTML tal com va arribar del servidor, abans que s'executi res. L'inspector d'elements, en canvi, mostra el DOM ja construït. La diferència entre aquestes dues vistes és exactament la diferència entre el que envia el servidor i el que fabrica React.

La seqüència real, pas a pas, quan algú obre la fitxa de bici-002:

Hi ha tres viatges d'anada i tornada encadenats abans que aparegui el model de la bicicleta: l'HTML, el JavaScript i les dades. I són seqüencials: el navegador no pot demanar les dades fins que no ha executat el JavaScript, i no pot executar el JavaScript fins que no ha rebut l'HTML que hi fa referència.

Traduït a les mètriques que es fan servir per mesurar l'experiència real:

El TTFB enganya: és excel·lent, però el que arriba en aquest primer byte no serveix de res. El que l'usuari percep és el FCP i el LCP, i tots dos són al final d'una cadena d'esperes.

Ara afegeix la variable que s'oblida quan es desenvolupa en un portàtil amb fibra: no tothom té la teva connexió ni el teu mòbil. Al mòdul 8 ja vam veure que analitzar i executar JavaScript en un mòbil de gamma mitjana va entre 3 i 5 vegades més lent. Sobre una xarxa 4G amb congestió, els 270 KB comprimits triguen més d'un segon només a arribar.

I hi ha un cas pitjor que el lent: el que falla. Si el fitxer de JavaScript no es descarrega —xarxa inestable, un bloquejador massa agressiu, un error de desplegament al CDN—, l'usuari no veu una versió degradada de CicloUrbano. Veu una pàgina en blanc. Amb HTML renderitzat al servidor, aquest mateix usuari veu el contingut; el que perd és la interactivitat, que és una degradació molt més raonable.

Idea clau. Una SPA fa que el contingut depengui del codi. El renderitzat al servidor trenca aquesta dependència: el contingut arriba com a contingut, i el codi només hi afegeix interactivitat a sobre.

Aquest és l'argument que sol decidir la migració, perquè és diners.

Imagina la fitxa pública de bici-002, l'Elèctrica Pro de Plaça Major. A la SPA, l'HTML que arriba és el <div id="root"> buit i un <title>CicloUrbano</title> genèric. Tota la resta —el nom del model, el preu de 4,00 €/h, el barri— apareix després, al DOM.

Què passa amb cada consumidor d'aquest HTML:

El cas de les targetes de previsualització és el més clar i el més fàcil de comprovar. Quan algú enganxa https://ciclourbano.test/bicicletas/bici-002 en un xat, l'aplicació de missatgeria fa una petició HTTP simple i busca a l'HTML les etiquetes <meta property="og:title">, og:description i og:image. No executa JavaScript, ni ara ni mai. Si aquestes etiquetes es posen des de React amb useEffect, l'aplicació de missatgeria mai les veurà.

Amb la SPA, la previsualització de qualsevol bicicleta del catàleg és idèntica:

Amb SSR, cadascuna és la seva:

La segona es comparteix; la primera no. I això és un problema de negoci, no de rendiment.

Aquesta taula és la columna vertebral del mòdul. Tot el que ve a 10-01 i 10-02 són notes al peu d'aquestes quatre files.

Aplicat a CicloUrbano, la lectura ràpida és:

• El panell de taller (/taller) és privat, personalitzat per rol i ningú l'indexa: CSR està bé.
• El catàleg públic amb disponibilitat en temps real canvia cada pocs minuts i ha de ser indexable: SSR.
• La pàgina de condicions del servei canvia dues vegades l'any: SSG.
• La fitxa d'una bicicleta canvia poc però canvia, i són centenars: ISR.

En aquesta lliçó construïm la columna del SSR. Les dues de la dreta són la lliçó següent.

Una precisió important per no confondre's des del principi: aquestes quatre estratègies no són marcs alternatius entre els quals cal triar-ne un per a tot el projecte. A Next.js amb App Router es trien ruta per ruta, i fins i tot dins d'una mateixa ruta es pot barrejar una part estàtica amb una illa dinàmica. Aquest és precisament el motiu que un framework aporti alguna cosa.

Amb SSR, el servidor genera l'HTML del catàleg i l'envia. El navegador el pinta immediatament: l'usuari veu les cinc targetes de bicicleta als 400 ms. Però aquest HTML és inert. Els botons no responen, el SelectorTipus no filtra, no hi ha estat, no hi ha gestors.

La hidratació és el procés pel qual React, ja al navegador, recorre aquest HTML existent i li «dona vida»: munta l'arbre de components, crea l'estat i connecta els gestors d'esdeveniments als nodes del DOM que ja hi són, sense tornar a crear-los.

És útil contrastar-ho amb el que ja coneixes:

La paraula clau és reutilitza. React parteix de la premissa que l'HTML del servidor és exactament el que ell mateix produiria en el primer render del client. Si aquesta premissa es trenca, apareix el problema de l'apartat següent.

I una conseqüència que convé interioritzar des d'ara: el SSR no elimina el JavaScript. El paquet es continua descarregant i executant. El que fa el SSR és desacoblar el moment en què es veu el contingut del moment en què l'aplicació és interactiva. Entre el FCP i el TTI hi ha ara una finestra en què la pàgina es veu però no respon: és el que s'anomena la «vall inquietant» de la hidratació. Reduir-la és precisament el que persegueixen els React Server Components de 10-03.

Un error d'hidratació (hydration mismatch) passa quan l'HTML que React genera al client durant el primer render no coincideix amb el que ha arribat del servidor. A React 19 el missatge és explícit i mostra un diferencial:

Les causes gairebé sempre són la mateixa família de problemes: alguna cosa que val diferent al servidor i al navegador.

El cas més freqüent a CicloUrbano és el tema fosc. El BotoTema llegeix la preferència desada a localStorage, i aquest codi s'executa durant el render:

En el servidor això ni tan sols arriba a discrepar: rebenta, perquè localStorage no està definit. El patró correcte separa el valor inicial segur del valor real:

Què fa cada peça:

• useState('clar') dona un valor determinista: el servidor i el primer render del client coincideixen, així que la hidratació és neta.
• El primer useEffect s'executa després de la hidratació, ja al navegador, on window existeix. Si la preferència desada era 'fosc', provoca un segon render i el tema canvia.
• El preu d'aquesta correcció és un parpelleig: durant uns mil·lisegons es veu el tema clar. La solució habitual —fora de l'abast d'aquesta lliçó— és un petit script en línia al <head> que fixa data-tema abans que es pinti res.

Regla pràctica. Durant el render, un component només pot fer servir informació que el servidor també té. Tota la resta —emmagatzematge, mida de la finestra, zona horària, aleatorietat— pertany a useEffect.

React porta la peça bàsica: renderToString a react-dom/server converteix un arbre de components en una cadena d'HTML. Amb això i un servidor Express es pot muntar un SSR mínim en vint línies.

I funciona… fins que vols qualsevol d'aquestes coses:

• Enrutament en dos llocs alhora, al servidor i al client, amb les mateixes rutes i sense duplicar la configuració.
• Precarregar les dades de la ruta abans de renderitzar, i després serialitzar-les a l'HTML perquè el client no les torni a demanar.
• Empaquetar dues compilacions diferents, la del servidor i la del client, amb codi compartit i amb CSS que arribi a la primera resposta.
• Dividir el codi per ruta i que el servidor sàpiga quins fragments precarregar a cada pàgina.
• Cachejar l'HTML per ruta, revalidar-lo, i decidir per ruta si és estàtic o dinàmic.
• Streaming, components de servidor, optimització d'imatges, capçaleres, sitemap.xml…

Cada punt és un projecte en si mateix, i la combinació de tots és un framework. Per això l'ecosistema no escriu SSR a mà: fa servir Next.js, Remix / React Router en mode framework, Astro o TanStack Start. En aquest curs fem servir Next.js, que és el més estès i el que desenvolupa el model de components de servidor que veuràs a 10-03.

Aquí convé ser explícit sobre què estem fent, perquè és fàcil perdre's:

No reescriurem CicloUrbano. L'aplicació de gestió amb Vite —catàleg intern, reserves, taller, Redux, TanStack Query, les proves del mòdul 9— continua existint tal qual. El que creem ara és un segon projecte, ciclourbano-web, l'aparador públic: les pantalles que es comparteixen, s'indexen i les veu gent que no ha iniciat sessió.

El criteri per decidir què va a l'aparador és senzill i es resumeix en tres preguntes:

Amb aquest filtre, es migren el catàleg públic, la fitxa de bicicleta, les pàgines d'estacions i el contingut informatiu. Es queden a Vite el panell de taller, la gestió de reserves i tot el que hi ha darrere de RutaProtegida.

Creació del projecte:

L'assistent pregunta. Aquestes són les respostes per a aquest mòdul:

Diem «no» a TypeScript perquè el veurem a 10-04 sobre el projecte Vite, i «no» a Tailwind perquè CicloUrbano ja fa servir CSS Modules, que Next.js suporta de fàbrica. App Router és obligatori per a tot el que ve ara.

El servidor arrenca a http://localhost:3000. Com que l'API fictícia continua sent json-server a http://localhost:3001, els dos processos conviuen sense tocar-se.

L'estructura rellevant després de la creació:

El primer que sorprèn és el que no hi ha: ni main.jsx, ni createRoot, ni index.html, ni rutes.jsx. Next.js s'encarrega de l'arrencada i de les rutes.

Traslladem les variables de CicloUrbano a src/app/globals.css sense canviar cap valor:

A React Router, una ruta és un objecte a rutes.jsx. A l'App Router de Next.js, una ruta és una carpeta, i dins seu certs noms de fitxer tenen un significat reservat.

Les carpetes que no contenen cap d'aquests fitxers no creen rutes: serveixen per organitzar. I hi ha dues convencions de nom molt útils:

• [bicicletaId] → segment dinàmic, equivalent a :bicicletaId.
• (escaparate) → grup de rutes: agrupa per compartir un layout sense afegir res a la URL.

La plantilla arrel és obligatòria i és l'única que conté <html> i <body>:

Tres coses a destacar:

• La prop es diu children, no <Outlet />. Next.js hi injecta la pàgina o la plantilla filla. És composició pura, com la del mòdul 4.
• metadata és un objecte exportat, no un component. El template: '%s · CicloUrbano' fa que qualsevol pàgina que exporti title: 'Estacions' acabi sent Estacions · CicloUrbano.
• Aquest component és un component de servidor: s'executa al servidor i no s'envia al navegador. Ho veurem a l'apartat 11.

Aquesta és la traducció literal del rutes.jsx de CicloUrbano a l'arbre de carpetes de l'aparador. Recorda que només migrem la part pública.

L'arbre resultant:

Compara-ho amb el diagrama de rutes imbricades del mòdul 6: és el mateix arbre. El que canvia és que a React Router ho declaraves i aquí ho dibuixes amb carpetes. La navegació també té la seva equivalència directa:

I aquí apareix la primera imbricació real, el layout de l'estació amb les seves pestanyes:

Punts importants:

• params és una promesa a Next.js 15. S'espera amb await. El mateix passa amb searchParams, cookies() i headers(). És un canvi respecte a versions anteriors i una font habitual de confusió en llegir tutorials antics.
• notFound() interromp el render i fa que Next.js serveixi el not-found.jsx més proper amb un codi HTTP 404 de veritat. A la SPA, PaginaNoTrobada es pintava amb un 200; els cercadors no distingien una fitxa esborrada d'una vàlida.
• La capçalera de l'estació es renderitza al layout, així que no es torna a demanar en canviar de pestanya: exactament el comportament que buscàvem amb les rutes imbricades del mòdul 6.

Aquest és el canvi conceptual més gran de la lliçó. A l'App Router, tots els components són components de servidor per defecte, i un component de servidor pot ser async.

Compara. Així demanava CicloUrbano el catàleg amb TanStack Query:

I així a Next.js:

Què ha desaparegut, i per què:

Hi ha un detall que mereix atenció especial: fetch('http://localhost:3001/...') s'executa al servidor Node, no al navegador. Això té tres conseqüències immediates:

• No hi ha CORS. És una petició de servidor a servidor.
• La URL de l'API pot ser privada. El navegador mai la veu. En producció, http://api.interna:3001 funcionaria perfectament.
• Es poden fer servir secrets. Una clau d'API a process.env.CLAVE_API no arriba mai al client. Això és un avantatge de seguretat enorme, i també un risc si t'equivoques de costat de la frontera (ho veurem a 10-03).

I el que puja al navegador d'aquest component és res. PaginaCataleg no forma part del paquet de JavaScript del client: només hi viatja el seu resultat. Aquest és el fons de l'assumpte que 10-03 desenvolupa.

Un apunt sobre peticions múltiples. Si la fitxa necessita la bicicleta i la seva estació, no les encadenis si no depenen l'una de l'altra:

Quan sí que hi ha dependència real —necessites bicicleta.estacioId per demanar l'estació— la cascada és inevitable, i aquí és on entra el streaming de l'apartat 16.

Un component de servidor no té estat, ni efectes, ni gestors d'esdeveniments: s'executa una sola vegada, al servidor, i no torna. Per recuperar tot això, es posa 'use client' a la primera línia del fitxer. Això marca aquest mòdul i tot el que importi com a codi de client: s'empaqueta, s'envia al navegador i s'hidrata, i allà tornen a funcionar useState, useEffect, onClick i les APIs del navegador. A CicloUrbano ho portaran SelectorTipus, BotoTema, MenuUsuari i el proveïdor de tema.

La frontera entre servidor i client, les seves regles exactes i el que pot i no pot travessar-la s'expliquen a fons a 10-03. De moment n'hi ha prou amb la regla operativa: si el component necessita estat, efectes o esdeveniments, 'use client' a dalt; si només pinta dades, no el posis.

És gairebé idèntic al SelectorTipus del mòdul 6: l'única cosa que canvia són els hooks de next/navigation en lloc dels de react-router. La lògica del filtre a la URL, que tant vam defensar en el seu moment, es trasllada intacta.

Next.js no renderitza al servidor a cada petició per defecte. El seu comportament per defecte és intentar prerenderitzar la ruta en la construcció (això és SSG, i és el tema de 10-02). Només passa a renderitzar a cada petició —renderitzat dinàmic, que és el SSR pròpiament dit— quan detecta que la ruta no es pot conèixer per endavant.

Aquests són els detonants:

Important a Next.js 15: fetch ja no es cacheja per defecte. Si no dius res, es comporta com no-store i la ruta passa a dinàmica. Perquè sigui estàtica cal demanar-ho (cache: 'force-cache' o next: { revalidate: N }). En versions anteriors era al revés, així que molt material antic diu el contrari.

A CicloUrbano, el catàleg públic és el cas de llibre del renderitzat dinàmic: mostra disponibilitat en temps real, així que servir HTML de fa mitja hora seria mentir a l'usuari.

Fixa't en tres decisions:

• El filtratge es fa al servidor. El que arriba al navegador és només l'HTML de les bicicletes visibles. A la SPA es descarregaven totes i es filtraven al client amb useCatalegFiltrat.
• SelectorTipus és de client, però LlistaBicicletes i ResumFlota són de servidor: no tenen estat, només pinten. No es descarreguen.
• En canviar el filtre, router.push provoca una nova petició al servidor que retorna l'HTML actualitzat. La navegació continua sent de client —no hi ha recàrrega completa— però el contingut el genera el servidor.

Pots verificar que funciona: Ctrl+U sobre http://localhost:3000/?tipo=electrica i busca «Elèctrica Pro» al codi font. Allà és, a l'HTML, abans de qualsevol JavaScript.

Tota la promesa de l'apartat 3 es compleix aquí. Next.js ofereix dues vies: l'exportació estàtica metadata, que ja has vist, i la funció generateMetadata per als casos en què el títol depèn de les dades.

Detalls que importen:

• generateMetadata i el component demanen les mateixes dades, i tanmateix json-server només rep una petició: Next.js dedupliqua automàticament els fetch idèntics dins del mateix render. Això s'anomena request memoization i evita haver de passar dades entre tots dos.
• openGraph i twitter produeixen les etiquetes <meta property="og:..."> que llegeixen WhatsApp, Slack i LinkedIn. Amb això, bici-002 compartida en un xat mostra la seva pròpia targeta.
• alternates.canonical evita contingut duplicat si la mateixa fitxa és accessible per diverses URL.
• El title es combina amb el template de la plantilla arrel: el resultat final és Elèctrica Pro · 4.00 €/h · CicloUrbano.

Per comprovar el resultat sense desplegar res:

A la SPA, la sessió de CicloUrbano viu a sliceSessio i es persisteix a localStorage amb useMagatzemLocal. Al servidor aquest mecanisme no existeix, i no és un detall d'implementació: és una conseqüència lògica. El servidor renderitza l'HTML abans que el navegador executi res, així que només pot saber de la sessió el que arribi a la mateixa petició HTTP.

I en una petició HTTP la sessió viatja a les cookies, que es llegeixen amb cookies():

Comparació dels dos models:

La conclusió pràctica és doble. Primer: el MenuUsuari amb el nom correcte arriba ja a l'HTML, sense el parpelleig de «convidat → Ana Ribera» que tenia la SPA. Segon, i més important: una cookie HttpOnly és més segura que localStorage, perquè un atac de XSS no la pot llegir des de JavaScript. Si l'aparador i la SPA comparteixen sessió, la cookie és el mecanisme correcte per als dos.

Tingues present que fer servir cookies() converteix la ruta en dinàmica, i com que aquí s'usa a la plantilla arrel, tota l'aplicació passa a renderitzar-se a cada petició. És un preu alt. La manera d'evitar-ho —moure la lectura de la cookie a un component petit embolcallat en <Suspense>, deixant la resta estàtica— és material de 10-02 i 10-03.

Queda una peça per anomenar. Amb el que hem vist fins ara, el servidor espera a tenir totes les dades, renderitza tot l'HTML i l'envia de cop. Si la disponibilitat d'una bicicleta triga 800 ms a calcular-se, l'usuari espera 800 ms sense veure res, igual que abans: hem canviat el lloc on s'espera, no el fet d'esperar.

El streaming trenca això: el servidor envia primer el marc de la pàgina —capçalera, títol de la bicicleta, peu— i va enviant els trossos que falten a mesura que es resolen, sense tancar la connexió. A Next.js s'activa de dues maneres:

• Posant un loading.jsx a la carpeta de la ruta, que Next.js converteix automàticament en un <Suspense fallback={...}> al voltant de la pàgina.
• Embolcallant a mà la part lenta en <Suspense> dins del component.

Reconeixeràs el mecanisme: és exactament el <Suspense fallback> de 08-04, aplicat a dades en lloc de a codi. I aquesta és la promesa que va quedar pendent aleshores: el mecanisme complet de Suspense, el streaming de l'HTML i el model de components de servidor que hi ha darrere de tota aquesta lliçó són el contingut de 10-03.

• Creure que el SSR elimina el JavaScript. No ho fa: el paquet es descarrega igual i l'aplicació s'hidrata. El que millora és quan es veu el contingut, no quant pesa. Si el teu problema és el pes, la solució continua sent la del mòdul 8.
• Fer servir window, document o localStorage durant el render. Al servidor no existeixen i el render falla amb ReferenceError. Van dins de useEffect, sempre.
• Posar 'use client' a la plantilla arrel «perquè tot funcioni». És la manera més ràpida d'anul·lar tots els avantatges: tot l'arbre passa a ser de client. La regla és la contrària: la frontera, tan avall com sigui possible.
• Oblidar await a params, searchParams, cookies() o headers(). A Next.js 15 són promeses. Sense await obtindràs un objecte estrany o un avís, i molts tutorials anteriors a la versió 15 els fan servir sense esperar.
• Suposar que fetch es cacheja. A Next.js 15 el comportament per defecte és no cachejar. Si vols memòria cau, demana-la explícitament (10-02).
• Renderitzar dates amb toLocaleString() sense fixar zona ni idioma. El servidor està en UTC; el navegador, no. És la causa número u dels errors d'hidratació. Fes servir timeZone i locale explícits, o formata en un efecte.
• Migrar l'aplicació sencera de cop. L'aparador públic i el panell de gestió tenen requisits oposats. Migra el que guanya amb SSR i deixa la resta com a SPA: és una arquitectura legítima, no una solució a mitges.
• No comprovar el resultat a l'HTML cru. Ctrl+U o curl són l'única manera honesta de saber què arriba realment. L'inspector d'elements sempre mostra la pàgina ja hidratada i et donarà una falsa sensació d'èxit.
• Consell: no portis TanStack Query a l'aparador per inèrcia. En un component de servidor no aporta res, perquè no hi ha memòria cau de client a gestionar. Continua sent l'eina correcta a la SPA de Vite i a les illes de client que necessitin dades.

Exercici 1. Per a cada pantalla de CicloUrbano, tria l'estratègia de renderitzat més adequada (CSR, SSR, SSG o ISR) i justifica-la en una frase. Indica també si va a ciclourbano-web o es queda a la SPA de Vite.

Exercici 2. Aquest component provoca un error d'hidratació i, a més, una fallada al servidor. Identifica els tres problemes i reescriu-lo.

Exercici 3. Crea la ruta /estaciones/[estacionId]/incidencias de l'aparador. Ha de: demanar les incidències a http://localhost:3001/incidencias?estacioId=<id> sense memòria cau, retornar un 404 real si l'estació no existeix, exportar un generateMetadata amb el títol Incidències de <nom de l'estació>, i mostrar un missatge quan no hi hagi cap incidència. Indica també quins fitxers addicionals crearies en aquesta carpeta i per a què.

Solució 1.

Solució 2. Els tres problemes són:

1. localStorage.getItem durant el render: no existeix al servidor i el render falla amb ReferenceError.
2. Math.random(): produeix un valor diferent al servidor i al client → discrepància d'hidratació.
3. new Date().toLocaleTimeString(): el servidor està en UTC i el navegador en una altra zona → una altra discrepància. A més, l'onClick obliga que el component sigui de client.

Claus de la correcció: la referència aleatòria es genera al servidor i es passa com a prop, així l'HTML i la hidratació coincideixen; l'emmagatzematge i l'hora es llegeixen a useEffect, després d'hidratar; i els valors que encara no existeixen es renderitzen condicionalment per no produir diferències.

Solució 3.

Fitxers addicionals en aquesta carpeta i el seu motiu:

• loading.jsx: mentre es demanen les incidències, la capçalera de l'estació (que és al layout del nivell superior) continua visible i només la pestanya mostra el seu esquelet.
• error.jsx: si json-server falla, es captura allà sense tombar la capçalera ni les pestanyes; ha de portar 'use client' i rep les props error i reset.
• not-found.jsx: opcional, per donar un missatge específic d'estació inexistent en lloc del genèric de l'arrel.

Fixa't en l'elegància de la imbricació: els tres fitxers només afecten el subarbre de la pestanya, exactament com els LimitError per zona del mòdul 4.

Aquesta lliçó ha travessat la frontera que anunciava el tancament del mòdul 9. El punt de partida era un <div id="root"> buit i tres viatges encadenats —HTML, JavaScript, dades— abans de veure una bicicleta; el punt d'arribada és un servidor que envia l'HTML de bici-002 ja construït, amb el seu títol, el seu preu i les seves etiquetes Open Graph, a punt per al navegador, per a Google i per a la targeta de previsualització d'un xat.

Queden fixades les quatre estratègies de renderitzat, que són el mapa de tot el mòdul: CSR genera l'HTML al navegador i serveix per al que és privat i interactiu; SSR el genera a cada petició i serveix per al que és fresc i indexable; SSG el genera un cop en la construcció; i ISR el regenera cada cert temps. I queda clar que no se'n tria una per a tot el projecte, sinó una per ruta.

Del funcionament, l'essencial és la hidratació: el servidor envia HTML inert i React el reutilitza al navegador per enganxar-hi estat i gestors. D'aquí surt l'única regla que cal interioritzar de veritat: durant el render, un component només pot fer servir informació que el servidor també té. Data local, Math.random(), localStorage, window i la mida de la finestra viuen a useEffect, no al cos del component.

En eines queda en marxa ciclourbano-web, un projecte Next.js 15 amb App Router que conviu amb la SPA de Vite sense substituir-la, amb el criteri de repartiment explícit: a l'aparador va el que és públic, indexable i compartible —catàleg, fitxa de bicicleta, estacions, informatives—; a la SPA es queden /acceso, /reservas i /taller. Les rutes es dibuixen amb carpetes (page, layout, loading, error, not-found, [bicicletaId]), l'<Outlet /> es converteix en children, les dades es demanen amb async/await dins del propi component de servidor —sense useEffect, sense useQuery, sense estats de càrrega manuals—, i params, searchParams, cookies() i headers() són promeses a Next.js 15. El renderitzat dinàmic s'activa quan la ruta no es pot conèixer per endavant, i el catàleg amb disponibilitat en viu l'activa amb cache: 'no-store'. El SEO deixa de ser un problema amb metadata i generateMetadata, i la sessió passa de localStorage a cookies, que a més és l'opció més segura.

Han quedat dos deutes explícits, i tots dos es paguen aviat. El primer és la directiva 'use client', que aquí has fet servir com una regla operativa i que a 10-03 s'explica com el que és: la frontera entre dos mons. La segona és el streaming, que hem anomenat sense desenvolupar.

Però abans cal tancar la meitat dreta de la taula d'estratègies. Fixa't que en tota la lliçó hem forçat el renderitzat dinàmic amb cache: 'no-store', com si el servidor hagués de treballar a cada visita. Per al catàleg amb disponibilitat en viu té sentit; per a les condicions del servei, que canvien dues vegades l'any, és un malbaratament absurd: s'està generant el mateix HTML milers de vegades al dia. La pròxima lliçó va a l'altre extrem —generar l'HTML una sola vegada, en la construcció— i després busca el punt intermedi que resol el 90 % dels casos reals: la regeneració incremental. La pròxima lliçó és Generació de Llocs Estàtics (SSG) amb Next.js.