CicloUrbano funciona i està provada, però viu a localhost, amb una base de dades que és un fitxer JSON i un servidor de desenvolupament que mai no hauria d'assomar-se a internet. Aquesta lliçó cobreix l'últim tram: convertir el projecte en un paquet de fitxers estàtics, entendre què es pot i què no es pot amagar en una aplicació que s'executa al navegador d'una altra persona, resoldre el problema d'enrutament que fa que /reservas retorni un 404 tan bon punt surt de localhost, desplegar-lo, i saber què vigilar després. I com que és l'última lliçó del curs, tanca també el camí recorregut i assenyala per on continuar.

1. La construcció per a producció
2. Revisar la mida abans de publicar
3. Variables d'entorn: què és realment públic
4. El 404 en recarregar: enrutament en client sobre un servidor estàtic
5. Desplegament pas a pas en una plataforma estàtica
6. L'alternativa del contenidor: Docker i Nginx
7. L'API en producció: què falta de veritat
8. Després del desplegament: monitorització i mètriques reals
9. Llista de comprovació de llançament
10. Següents passos amb aquest projecte
11. Com continuar aprenent

Fins ara tot ha passat amb npm run dev, on Vite serveix els mòduls sense empaquetar i recarrega en calent. Això és còmode per desenvolupar i no és el que es publica. La construcció és una altra cosa:

Què ha fet, pas a pas:

Aquest hash és la peça que més es malinterpreta. Serveix per poder dir-li al servidor «guarda aquests fitxers en memòria cau per sempre» sense condemnar l'usuari a una versió antiga: si el contingut canvia, el nom canvia, i el navegador el demana com si fos un fitxer nou. La conseqüència pràctica és una regla de memòria cau de dues velocitats:

Abans de publicar, es verifica la construcció tal qual, no el servidor de desenvolupament:

És el moment de comprovar tres coses que només es veuen aquí: que no hi ha errors a la consola sense els avisos de desenvolupament, que els fragments mandrosos es descarreguen en navegar (mira la pestanya de xarxa) i que el Suspense de cada ruta mostra el seu esquelet i no un salt en blanc.

L'informe de dalt ja dona la xifra que importa: 87,65 kB comprimits per al paquet principal. La revisió útil no és «és molt?» en abstracte, sinó comparar amb el pressupost que es va fixar i localitzar qui ocupa què:

Un desglossament típic d'aquest projecte:

La lliçó: en una aplicació ben dividida, el pes és gairebé tot dependències, i la palanca que queda no és minificar millor, sinó triar menys biblioteques. Si el pressupost se supera, la conversa és sobre arquitectura, no sobre configuració.

Vite exposa al codi només les variables que comencen per VITE_, i les substitueix a la construcció:

I ara l'advertència més important d'aquesta lliçó, perquè és un error que es comet amb freqüència i té conseqüències reals:

Tot el que posis a import.meta.env acaba escrit, en text llegible, dins dels fitxers JavaScript que es descarrega qualsevol persona que visiti la web. No és una variable «de servidor»: és una constant que s'incrusta al paquet. Qualsevol pot obrir les eines del navegador i llegir-la.

D'aquí es deriva una frontera clara:

El que necessiti un secret necessita un servidor que el guardi i faci la crida per tu. No hi ha drecera. I .env.production no es versiona: al repositori hi va .env.example amb les claus i sense els valors, i els valors reals es configuren a la plataforma de desplegament.

Aquesta és la fallada que sorprèn tothom en el seu primer desplegament d'una aplicació d'una sola pàgina. En local funciona; desplegat, entrar directament a https://ciclourbano.example/reservas retorna un 404.

La raó és que hi ha dues entitats diferents resolent rutes i només una coneix les teves:

React Router viu dins del JavaScript que carrega index.html. Si el servidor no lliura index.html, no hi ha React, no hi ha Router i no hi ha ruta. La solució és sempre la mateixa idea —retornar index.html per a qualsevol ruta que no sigui un fitxer real— amb una sintaxi diferent a cada plataforma:

Fixa't en el detall del codi 200 a Netlify: és una reescriptura, no una redirecció. La URL que veu l'usuari continua sent /reservas, que és justament el que React Router necessita llegir. Amb un 301 o un 302 la URL canviaria a / i l'usuari acabaria al catàleg.

I la comprovació que mai no s'ha de saltar després de desplegar: obrir una ruta profunda en una pestanya nova i recarregar-la. Navegar-hi des de l'inici no prova res, perquè aquest camí mai no toca el servidor.

El projecte són fitxers estàtics, així que gairebé qualsevol allotjament serveix. Amb una plataforma connectada al repositori, el desplegament queda automatitzat:

Pas 1. Puja el projecte a un repositori remot (GitHub, GitLab). El flux de treball de CI escrit a la lliçó anterior comença a executar-se a cada canvi.

Pas 2. Connecta el repositori a la plataforma i configura la construcció:

Pas 3. Afegeix les variables d'entorn al panell de la plataforma: VITE_API_URL amb la URL real de l'API i VITE_ENTORN=produccion. Mai al repositori.

Pas 4. Afegeix el fitxer de reescriptura de la secció anterior. Sense ell, el desplegament «funciona» fins que algú comparteix un enllaç.

Pas 5. Desplega i comprova, en aquest ordre: la portada carrega; una ruta profunda recarregada en pestanya nova funciona; el catàleg porta dades de l'API real; una ruta inexistent mostra la teva pàgina de no trobat; el panell de taller continua vedat a un client; i la consola està neta.

Pas 6. Activa els desplegaments de vista prèvia per branca. Cada branca i cada sol·licitud de canvis obté la seva pròpia URL temporal, així que les revisions deixen de ser «confia en mi» i passen a ser «prova-ho aquí». És, de bon tros, la funció que més canvia la forma de treballar en equip.

Si el desplegament va a la infraestructura pròpia de l'empresa, la forma equivalent és una imatge que construeix i serveix:

Dos detalls que convé entendre. El primer és que la construcció de dues etapes deixa una imatge final d'uns pocs megabytes: Node només existeix mentre es construeix. El segon és l'ARG VITE_API_URL: com que les variables s'incrusten a la construcció, una imatge construïda apunta a una API concreta. No la pots canviar en arrencar el contenidor. Si necessites una imatge que serveixi diversos entorns, la URL s'ha de llegir en temps d'execució (per exemple, d'un /configuracio.json que es demana en arrencar l'aplicació).

Cal dir-ho sense adorns: json-server és una eina de desenvolupament. Accepta qualsevol escriptura de qualsevol, no té autenticació, no valida res i guarda les dades en un fitxer. Desplegar-lo amb dades reals seria un incident de seguretat, no un desplegament.

El que fa falta darrere d'una aplicació com aquesta:

Val la pena rellegir amb aquesta llum el que es va dir a Rutes Protegides: RutaProtegida i RequereixRol milloren l'experiència i no protegeixen res. Qualsevol pot obrir les eines del navegador, modificar l'estat de la sessió i veure la pantalla del taller. El que impedeix que faci mal no és el teu component: és el servidor rebutjant la petició.

Un últim avís de sensatesa professional: tan bon punt hi hagi dades de persones reals pel mig —noms, correus, ubicacions, pagaments— el disseny d'autenticació, emmagatzematge i permisos l'ha de revisar algú amb experiència en seguretat i protecció de dades abans d'exposar-lo al públic. Tot el domini d'aquest curs és fictici precisament per poder aprendre sense aquest risc.

Publicar no és acabar. En producció hi ha navegadors, xarxes i persones que no eren al teu portàtil, i hi ha dues preguntes que només es responen amb dades d'allà.

Falla alguna cosa? El registrarError de src/utilitats/monitoritzacio.js porta tot el curs sent un console.error. Ara és quan connecta amb un servei de veritat:

Aquest enganxament ja està posat on tenia que estar: el componentDidCatch del LimitError que es va escriure a Límits d'Error. El valor d'haver-ho previst llavors es cobra ara.

Va ràpida per a la gent de veritat? Els mesuraments del Profiler es van fer en un portàtil amb bona xarxa. Les mètriques d'usuaris reals es recullen al mateix navegador i s'envien:

I fa falta una tercera cosa que no és tècnica: un canal de tornada. Un enllaç visible per informar d'un problema, i algú que el llegeixi. La majoria de les fallades que importen les explica una persona abans que cap mètrica les delati.

El punt que més s'oblida i més fa mal és el pla de reversió. Abans de publicar, cal saber com es torna a la versió anterior i quant triga. Les plataformes connectades al repositori ho donen fet amb un botó; amb contenidors, és tornar a desplegar l'etiqueta anterior. Esbrina-ho abans de necessitar-ho.

CicloUrbano és viva i té un full de ruta natural, tot ell recolzat en el que ja saps:

El millor consell per triar és el mateix que va ordenar el projecte des del principi: increments verticals. Una millora completa, de la interfície a la prova, abans de començar la següent.

• La documentació oficial de React és, avui, excel·lent. Les seves pàgines sobre «no necessites un efecte» i sobre com estructurar l'estat expliquen millor que cap tutorial per què les coses són com són. Torna-hi amb l'experiència que ja tens: es llegeixen diferents.
• Llegeix el codi de les biblioteques que fas servir. React Router, Redux Toolkit i TanStack Query són llegibles i estan ben escrites. Entendre com resolen un problema ensenya més que qualsevol curs, inclòs aquest.
• Escriu la teva pròpia versió reduïda d'alguna cosa que facis servir: un useQuery mínim amb memòria cau, un enrutador de cinquanta línies. Res consolida un model mental com reimplementar-lo.
• Reprodueix les fallades que trobis en un exemple mínim abans de demanar ajuda. La meitat de les vegades es resolen en l'intent, i l'altra meitat reps una resposta molt millor.
• Contribueix. Comença per documentació i per reproduir incidències; és la porta d'entrada més honesta a un projecte de codi obert.
• Mantén l'escepticisme amb el que és nou. L'ecosistema de React es mou ràpid i no tot el que apareix sobreviu. La manera de distingir la moda de la millora és preguntar-se quin problema concret resol i si tu el tens.

• Desplegar sense la regla de reescriptura. L'aplicació sembla funcionar fins que algú recarrega o comparteix un enllaç. Comprova sempre una ruta profunda en pestanya nova.
• Posar un secret en una variable VITE_. Queda en text llegible al paquet. Si alguna cosa ha de ser secreta, necessita un servidor.
• Guardar en memòria cau index.html durant molt de temps. Els usuaris es queden clavats a la versió anterior encara que els assets nous ja estiguin publicats. index.html sense memòria cau, assets amb hash i memòria cau llarga.
• Confiar en RutaProtegida com a seguretat. És experiència d'usuari. L'autorització es comprova al servidor, a cada endpoint, sempre.
• Provar el rendiment al servidor de desenvolupament. Els números no s'assemblen als de producció. Mesura sobre npm run preview o sobre el desplegament real.
• Desplegar un divendres a la tarda sense pla de reversió. No és una broma: si no saps com tornar enrere i quant triga, no estàs a punt per publicar.
• Consell final: automatitza el desplegament el mateix dia que en facis el primer a mà. Un desplegament que requereix recordar passos és un desplegament que algú farà malament.

Exercici 1. Desplega CicloUrbano en una plataforma estàtica amb la reescriptura correcta i les capçaleres de memòria cau de la secció 1. Documenta al README.md el procediment i el pla de reversió, i verifica amb grep sobre dist/ que no s'ha colat cap secret.

Exercici 2. Prepara el projecte per servir-se des d'una subruta (https://ejemplo.example/ciclourbano/) en lloc de l'arrel del domini. Esbrina què cal canviar a Vite, a React Router i a la configuració del servidor.

Exercici 3. Afegeix al flux d'integració contínua un pas que faci fallar la construcció si el paquet principal supera un pressupost de 100 kB comprimits, perquè la mida no es degradi sense que ningú se n'adoni.

Solució 1.

Al README.md:

Solució 2. Cal tocar tres llocs, i oblidar-se de qualsevol d'ells produeix una pantalla en blanc o enllaços trencats:

Comprovació: dist/index.html ha de referenciar /ciclourbano/assets/..., i una recàrrega a /ciclourbano/reservas ha de funcionar. Els enllaços interns amb <Link to="/reservas"> es continuen escrivint sense el prefix: l'afegeix el basename.

Solució 3.

La clau és el process.exit(1): sense ell, l'script informa però la integració contínua continua en verd i el pressupost es converteix en un suggeriment que ningú atén.

Vas començar aquest curs amb un <div id="root"> buit i la pregunta de per què algú necessitaria una biblioteca per pintar una llista de bicicletes. Acabes amb una aplicació completa, provada en quatre nivells, mesurada, dividida en fragments, accessible i desplegada, i amb criteri propi per decidir com construir la següent.

El camí ha estat aquest. Als fonaments vas entendre que React és declaratiu i que la interfície és una funció de l'estat, i vas veure què passa de veritat entre un canvi d'estat i un píxel a la pantalla. Amb els components, les props i l'estat vas aprendre a delimitar peces i a parametritzar-les, i amb els esdeveniments, els formularis i l'accessibilitat vas fer que responguessin a persones, no només a dades. Als conceptes avançats va aparèixer la disciplina: elevar l'estat a l'avantpassat comú, compondre en lloc d'heretar, i capturar les fallades abans que es mengin la pantalla. Els hooks et van donar el vocabulari complet —estat, sincronització amb l'exterior, referències, context, reductors— i, sobretot, la capacitat d'extreure la teva pròpia lògica reutilitzable. React Router va convertir una pantalla en una aplicació amb URLs compartibles i accessos controlats. La gestió de l'estat va posar ordre en el caos amb una idea que val més que qualsevol biblioteca: cada dada té un lloc on ha de viure, i les dades del servidor no són teves. El rendiment et va ensenyar a mesurar abans de tocar i a no confondre optimització amb decoració. Les proves et van donar la llibertat de refactoritzar sense por, provant comportament i no implementació. Els temes avançats van ampliar el mapa fins al servidor, els tipus i el mòbil. I el projecte va demostrar que tot això encaixa.

El que t'emportes no és una llista d'APIs, que canviaran. És la manera de pensar que hi ha a sota: descriure la interfície en funció de l'estat, posar cada dada al seu lloc, mesurar abans d'optimitzar, provar el comportament visible, i no confiar mai en el client per al que ha de garantir el servidor. Això continua sent cert quan canvia la versió, la biblioteca de moda o el framework sencer.

Ja tens el que fa falta. Construeix alguna cosa.