El mòdul anterior es va tancar amb un deute molt concret: SelectorTipus guarda el tipus triat en el seu propi estat i avisa el pare, però el catàleg continua mostrant les cinc bicicletes fem el que fem; i TargetaBicicleta avisa amb alSeleccionar, però App només pot fer un console.log perquè no té on guardar la bicicleta seleccionada. Les dues coses fallen pel mateix motiu: l'estat és privat de cada component, i dos germans mai poden veure's l'estat l'un a l'altre. En aquesta lliçó aprendràs la tècnica que resol això —elevar l'estat (lifting state up)—, l'aplicaràs perquè el filtre de CicloUrbano funcioni de debò, entendràs per què duplicar la mateixa dada en dos llocs és una font garantida d'errors i veuràs el preu que es paga en elevar: la perforació de props.

1. El problema: dos germans i una dada compartida
2. La regla: pujar a l'avantpassat comú més proper
3. El refactor de CicloUrbano, pas a pas
4. App amb estat: tipusTriat i bicicletaSeleccionada
5. Estat derivat: bicicletesVisibles no és estat
6. El flux unidireccional, vist sencer
7. Una única font de veritat: l'error de duplicar
8. Components controlats i no controlats, a nivell de component
9. Què NO convé elevar
10. El cost d'elevar: la perforació de props

Aquest és l'arbre de CicloUrbano tal com va quedar al final del mòdul 3:

La fletxa creuada és el problema. tipusTriat viu dins de SelectorTipus, i des d'allà la dada només pot viatjar cap avall (als fills de SelectorTipus, que no en té) o cap amunt (avisant el pare amb una prop de funció). El que no existeix a React és un camí lateral: un component no pot llegir l'estat del seu germà.

I no és una limitació capritxosa. Si LlistaBicicletes pogués llegir l'estat de SelectorTipus, tots dos quedarien acoblats: no podries reutilitzar la llista en una altra pantalla sense arrossegar el selector, i per entendre per què la llista mostra el que mostra hauries de llegir un component que no apareix en el seu codi. React tria la restricció a propòsit, i a canvi ofereix una regla senzilla per resoldre-ho.

Quan dos o més components necessiten la mateixa dada, aquesta dada ha de viure en l'estat de l'avantpassat comú més proper, i baixar a cadascun com a prop.

La tècnica es diu elevar l'estat i consta de tres moviments:

El component que perd l'estat no es queda mut: rep dues props en el seu lloc.

• El valor actual (tipusTriat), per pintar-se.
• Una funció d'avís (alCanviarTipus), per demanar al pare que el canviï.

Si això et sona, és perquè és exactament el patró que vas fer servir a 03-04 amb un <input> controlat: value + onChange. La diferència és que allà el component controlat era una etiqueta del DOM i aquí és un component teu. El patró és el mateix, i hi tornarem a l'apartat 8.

Aquesta és la versió de 03-01, la que substituirem:

I aquesta és la nova:

Canvis i per què:

• Desapareixen useState i el seu import. El component ja no recorda res: tot el que pinta surt de les seves props. S'ha convertit en un component de presentació pur, dels que vas veure a 02-01.
• alCanviarTipus passa de opcional a obligatòria. Abans era un afegit: el selector funcionava sense ella perquè es pintava amb el seu propi estat. Ara és l'única via de canvi; sense aquesta prop el component seria un adorn que no respon. Documenta-ho al bloc /** Props: … */.
• El botó actiu es decideix amb tipusTriat, que ara arriba de fora. El JSX no ha canviat ni una línia: li és igual d'on vingui el valor.
• aria-pressed comunica l'estat del botó a les tecnologies d'assistència, seguint el que vas aprendre a 03-06: la selecció no es pot informar només amb el color del CSS.

El que ha passat aquí és tot el mòdul condensat en un fitxer:

• App per fi té estat, i són exactament dues dades: quin filtre està actiu i quina bicicleta està seleccionada. Ni una més.
• LlistaBicicletes rep bicicletesVisibles, no bicicletes. El component no s'ha modificat: continua rebent un array i pintant-lo amb map. Ni tan sols sap que existeix un filtre, i aquesta ignorància és una virtut, perquè el fa reutilitzable en qualsevol pantalla.
• PanellReserva rep per fi una bicicleta de debò. Els retorns anticipats que vas escriure a 03-02 —«Selecciona una bicicleta del catàleg» quan falta la prop— deixen de ser una hipòtesi: amb bicicletaSeleccionada a null en arrencar, aquest és literalment el primer estat que veu la persona usuària.
• gestionarConfirmacio neteja la selecció posant-la a null, amb la qual cosa el panell torna al seu missatge inicial. Un cicle complet, sense trucs.

I LlistaBicicletes es beneficia d'una cosa que ja tenia escrita: el seu estat buit. Si filtres per «De càrrega» i l'única bicicleta de càrrega és al taller, el bicicletes.length === 0 que vas programar a 03-03 es dispara i mostra el missatge. No has hagut d'escriure res de nou.

Les dades baixen per props (fletxes contínues) i els avisos pugen per funcions (fletxes discontínues). No hi ha cap fletxa horitzontal: els germans continuen sense parlar-se, es comuniquen a través del pare.

Quan l'estat puja, la temptació és pujar-ho tot. Aplica aquest filtre a cada dada abans de convertir-la en estat del pare:

A CicloUrbano, tipusTriat i bicicletaSeleccionada passen les dues primeres preguntes i no passen la tercera: no hi ha manera de deduir-los de res. Són estat legítim.

Un detall sobre bicicletaSeleccionada: hi guardem l'objecte sencer, no el seu id. Amb dades estàtiques importades de domini.js funciona perfectament. Quan les dades vinguin d'un servidor i puguin actualitzar-se (Mòdul 7), la pràctica recomanada serà guardar l'id i buscar l'objecte al vol, perquè un objecte guardat en estat és una còpia congelada que no s'assabenta si l'original canvia. És el mateix avís sobre duplicació que apareix a l'apartat 7.

Aquest és l'error més comú en elevar. La versió incorrecta:

Funciona… fins que algú afegeix una altra manera de canviar el filtre i s'oblida de la segona línia. En aquell moment el selector diu «Elèctriques» i la llista mostra totes les bicicletes. El fallo no és al filtratge: és que la mateixa informació es guarda dues vegades i res no garanteix que coincideixin.

La versió correcta ja l'has vist: una sola línia, sense estat.

Es recalcula a cada render, que és exactament quan cal, i és impossible que es desincronitzi perquè no hi ha res a sincronitzar. És la mateixa lliçó de 02-04 —estat davant de valor derivat— aplicada ara a un component contenidor.

«No és ineficient filtrar a cada render?» Amb cinc bicicletes, o amb cinc-centes, no. filter sobre un array petit costa microsegons, molt menys que la complexitat de mantenir dos estats a mà. Si algun dia el càlcul és realment costós i ho has mesurat, existeix useMemo (08-03). Mesura primer, optimitza després.

Seguim un clic des del principi fins al final. Algú prem «Elèctriques»:

Fixa't en un detall important: SelectorTipus no canvia res per si mateix. Prems el botó i no passa res visible fins que App actualitza el seu estat i torna a renderitzar. El selector només demana el canvi. Si App decidís ignorar la petició —per exemple, prohibint el filtre «De càrrega» als clients—, el botó no s'activaria. Tota l'autoritat és en un únic lloc, i això fa que el comportament sigui predictible i depurable: si alguna cosa es veu malament, l'estat equivocat és a App.

Aquest cicle tancat és el que es coneix com a flux de dades unidireccional, i és el motiu pel qual una aplicació React gran es pot raonar llegint de dalt a baix.

El principi s'enuncia així: cada dada ha de tenir exactament un propietari. Qualsevol altre component que la necessiti la rep com a prop; ningú en fa una còpia local.

Vegem el fallo amb un exemple reproduïble. Imagina't que, després d'elevar l'estat, deixes també una còpia dins del fill «per comoditat»:

A primer cop d'ull funciona. Però conté dues bombes de rellotgeria:

1. useState(tipusTriat) només llegeix la prop en el primer render. És el valor inicial, no un vincle permanent. Si demà App afegeix un botó «Restablir filtres» que fa setTipusTriat('todos'), el pare dirà «todos» i el selector continuarà mostrant «Elèctriques» actiu. Per sempre.
2. Hi ha dues veritats alhora. Quin és el tipus triat de debò? Depèn de a qui preguntis. I depurar això significa mirar dos components a les DevTools i comparar.

La regla pràctica, sense excepcions que valgui la pena aprendre's ara:

A 03-04 i 03-05 vas aplicar aquests termes als camps d'un formulari. Ara s'apliquen igual a components que escrius tu, i la distinció és exactament la mateixa.

Un mateix component pot admetre les dues modalitats, i és un patró que veuràs en moltes biblioteques. La tècnica: si la prop de valor arriba definida, el component obeeix el pare; si no, gestiona el seu propi estat.

Les tres línies clau:

• const esControlat = obert !== undefined; El contracte és explícit: passar la prop significa «jo mano». Es compara amb undefined i no amb un valor falsy, perquè obert={false} és un valor perfectament vàlid que sí que ha d'activar el mode controlat.
• const estaObert = esControlat ? obert : obertIntern; La resta del component fa servir sempre aquesta variable i no s'assabenta de quin mode està actiu. Tota la bifurcació cap en una línia.
• if (!esControlat) setObertIntern(...) En mode controlat el component no toca el seu estat intern: només avisa. Actualitzar-los tots dos seria duplicar la veritat, l'error de l'apartat 7.

No cal que tots els teus components admetin les dues modalitats —afegeix complexitat— però convé saber-lo llegir, perquè és el disseny de gairebé qualsevol component de biblioteca que facis servir.

Elevar és una eina, no un dogma. Pujar estat que ningú més necessita empitjora el codi: obliga App a tornar a renderitzar l'arbre sencer per canvis que només afecten un racó, i omple el component arrel de dades irrellevants.

Casos clars d'estat que ha de quedar-se avall:

El cercador amb retard ho il·lustra bé:

Si text visqués a App, cada tecla premuda provocaria un render de l'arbre complet, inclòs el catàleg sencer. En quedar-se dins, només es torna a pintar l'<input>, i el pare se n'assabenta una vegada, quan hi ha alguna cosa a fer.

La pregunta de control és sempre la mateixa: algú més necessita aquesta dada per pintar-se o per decidir alguna cosa? Si la resposta és no, es queda on és. I si demà la resposta canvia, elevar-la és un refactor de deu minuts: no cal anticipar-se.

Elevar té un preu, i és honest conèixer-lo. Quan l'avantpassat comú és lluny, la dada ha de travessar tots els components intermedis, encara que a ells no els serveixi de res. Se'n diu perforació de props (prop drilling).

Imagina't que CicloUrbano creix i la targeta necessita saber el rol de l'usuari (usr-02 és operari i pot marcar manteniment):

Els símptomes són reconeixibles:

• Components intermedis amb props que només reenvien, sense fer-les servir.
• Afegir una dada nova obliga a tocar quatre fitxers perquè arribi a un.
• Reanomenar la prop obliga a un cercar-i-reemplaçar per tota la cadena.
• Els components intermedis perden reutilització: exigeixen una prop que no els importa.

Amb dos nivells no és un problema, i no convé arreglar-ho abans que faci mal. Amb quatre o cinc, sí. React té una resposta per a això: l'API de context, que permet posar un valor a disposició de tot un subarbre sense anar de mà en mà. La veuràs a useContext i, a escala d'aplicació sencera, al Mòdul 7, on també apareixen els gestors d'estat externs. Aquí només hem posat nom al problema.

• Copiar una prop en l'estat del fill. useState(props.valor) només llegeix la prop una vegada, en el primer render. A partir d'aquí les dues còpies se separen i mai més tornen a coincidir. Si necessites llegir i canviar la dada, rep-la per prop i avisa cap amunt.
• Guardar en estat el que es pot calcular. bicicletesVisibles, totals, comptadors, textos formatats: tot això és derivat. Cada estat afegit és una oportunitat més de desincronització.
• Elevar massa amunt «per si de cas». El destí correcte és l'avantpassat comú més proper, no l'arrel. Posar-ho tot a App converteix el component arrel en un abocador i provoca renders innecessaris.
• Oblidar-se de passar el callback. Si converteixes un component en controlat i oblides la prop de canvi, obtindràs un component inert que no respon als clics, sense cap error a la consola. Documenta les props obligatòries i considera un avís en desenvolupament.
• Passar el valor però no el gestor (o al revés). Un component controlat necessita les dues props: amb una de sola queda a mitges, igual que un <input value> sense onChange queda de només lectura.
• Consell: mira les DevTools. Selecciona App a React DevTools i veuràs els seus dos estats canviant en directe mentre premeu filtres i targetes. És la millor manera de confirmar que la font de la veritat és on creus.
• Consell: anomena les props del contracte. El parell tipusTriat / alCanviarTipus es llegeix com value / onChange. Mantenir aquesta simetria en tot el projecte fa que els components es facin servir sense consultar-ne el codi.

Exercici 1. Eleva l'estat del PanellReserva. Ara mateix rep hores com a prop fixa amb valor 2, així que no es pot canviar. Fes que App guardi horesReserva en el seu estat (valor inicial 2) i que PanellReserva rebi hores i una nova prop alCanviarHores, amb dos botons («−» i «+») que no baixin mai d'1 hora. El total s'ha de recalcular sol. Explica per què el total no ha de ser estat.

Exercici 2. Afegeix a App un comptador de resultats accessible. A sota del SelectorTipus, mostra un text del tipus «Es mostren 2 de 5 bicicletes», amb la concordança correcta en singular i plural, dins d'un element amb aria-live="polite" (03-06). No afegeixis cap estat nou: el text ha de sortir íntegrament de bicicletesVisibles i bicicletes.

Exercici 3. Detecta i corregeix la desincronització. Aquest component té l'error de l'apartat 7. Descriu-lo amb un cas concret que el faci fallar i reescriu-lo correctament.

Solució 1.

El total no és estat perquè es dedueix completament de bicicleta.preuHora i hores. Guardar-lo obligaria a recalcular-lo en dos llocs (en canviar les hores i en canviar de bicicleta) i n'hi hauria prou d'oblidar-ne un per mostrar un preu fals. El límit inferior s'aplica a App, la propietària de la dada, no al panell: així la regla viu al costat de l'estat.

Solució 2.

Sense estat nou: tots dos números surten d'arrays que ja existeixen. aria-live="polite" fa que el lector de pantalla anunciï el canvi en acabar de llegir el que estigui llegint, de manera que qui filtra amb el teclat sap quants resultats queden encara que no vegi la llista.

Solució 3. El fallo: useState pren el model una única vegada, en el primer render. Com que en arrencar bicicletaSeleccionada és null, model val 'Cap' per sempre; prem les cinc targetes i el text no canviarà mai. Ni tan sols un canvi posterior de bicicleta ho arregla, perquè l'estat ja està inicialitzat. És l'error clàssic de copiar una prop en l'estat.

El component passa a ser una funció pura de les seves props: per a les mateixes props, sempre la mateixa sortida. Impossible que es desincronitzi.

Elevar l'estat és la tècnica que converteix un conjunt de components solts en una aplicació. La regla cap en una frase: l'estat compartit viu a l'avantpassat comú més proper, baixa com a props i torna a pujar en forma d'avisos. Aplicant-la, CicloUrbano ha saldat el deute que arrossegava des del mòdul 2: SelectorTipus s'ha convertit en un component controlat sense estat propi, App guarda tipusTriat i bicicletaSeleccionada, bicicletesVisibles es calcula com a valor derivat —mai com a estat— i PanellReserva rep per fi una bicicleta real. El catàleg filtra de debò.

També has vist els límits de la tècnica. Elevar massa empitjora el codi: l'estat realment local —el text d'un cercador, si un panell està plegat— ha de quedar-se avall. I elevar lluny té un preu amb nom propi, la perforació de props, la resposta de la qual arribarà amb useContext i el Mòdul 7.

Queda una pregunta oberta que assoma tan bon punt la interfície creix: App ja comença a acumular seccions, i aviat necessitaràs embolicar el catàleg en un disseny amb capçalera i barra lateral, mostrar avisos de diversos tipus i crear panells reutilitzables. En altres llenguatges, la resposta seria l'herència: un PanellBase del qual heretin PanellCataleg i PanellReserves. A React aquesta resposta és l'equivocada, i la bona en té un altre nom. La pròxima lliçó és Composició vs Herència, on aprendràs a construir components a partir d'altres components sense heretar ni una sola vegada.