Portes dues lliçons arrossegant la mateixa limitació: el catàleg de CicloUrbano mostra tres targetes idèntiques perquè les dades de la bicicleta estan escrites dins de TargetaBicicleta. Un component així no és reutilitzable: només serveix per mostrar aquella bicicleta concreta. Les props són la solució, i són un dels dos o tres conceptes veritablement fonamentals de React. Una prop és una dada que un component rep des de fora, de qui l'utilitza. Converteixen un component rígid en una plantilla parametritzable, defineixen el contracte entre pare i fill i són la raó per la qual pots escriure TargetaBicicleta una vegada i utilitzar-la en cinc pantalles diferents. En aquesta lliçó aprendràs a passar-les i rebre-les, quins tipus de valors admeten, com donar-los valors per defecte, què és la prop especial children, per què són de només lectura i com documentar el contracte dels teus components. En acabar, el catàleg mostrarà per fi bicicletes diferents.

1. Què són les props i quin problema resolen
2. Passar props i rebre-les
3. Destructuring a la signatura del component
4. Quins tipus de valors es poden passar
5. Valors per defecte
6. La prop especial children
7. Les props són de només lectura
8. Difondre props amb l'operador de propagació
9. Documentar el contracte d'un component
10. El catàleg de CicloUrbano, ja parametritzat

Props ve de properties. Són les dades que flueixen des d'un component pare cap a un component fill a través dels atributs del JSX.

L'analogia més útil és la d'una funció: un component és una funció, i les props són els seus arguments.

Exactament el mateix passa amb els components:

L'analogia no és casual: les props són literalment els arguments de la funció component. React recull els atributs que escrius al JSX, els posa dins d'un objecte i li passa aquest objecte a la teva funció com a primer paràmetre.

I una propietat estructural molt important: el flux és unidireccional i descendeix per l'arbre. Un pare passa dades a un fill; un fill mai «retorna» dades escrivint sobre les seves props. Aquesta restricció, que d'entrada sembla limitant, és exactament el que fa predictible una aplicació React: per saber d'on surt una dada, puges per l'arbre; mai no has de buscar qui l'ha modificat per sorpresa.

Dues sintaxis conviuen, i la diferència és la que ja vas veure a la lliçó de JSX (01-04):

Un error clàssic: preuHora="2.5" passa la cadena "2.5", no el número. I "2.5".toFixed(2) no existeix, així que la targeta esclatarà. Si el valor no és text, va entre claus.

React crida la teva funció amb un únic objecte que conté tots els atributs que has escrit:

Tres detalls que convé fixar des del principi:

• El paràmetre es pot anomenar com vulguis. props és la convenció universal, però és un paràmetre normal. Anomena'l props.
• Els noms de les props els tries tu. No hi ha cap llista de props vàlides: són el vocabulari del teu component. Fes servir camelCase (preuHora, estacioId), igual que a JavaScript.
• Si no passes un atribut, aquesta prop val undefined. No dona error; simplement no hi és. Per això més endavant veurem els valors per defecte.

Escriure props. davant de cada valor és sorollós. El destructuring d'ES6 permet extreure les props directament a la signatura de la funció, i és la forma dominant al React modern.

Les claus de ({ model, tipus, estat }) no són un objecte: són la sintaxi de desestructuració aplicada al paràmetre. És equivalent a escriure const { model, tipus, estat } = props; a la primera línia del cos.

Per què és millor:

A CicloUrbano passarem la bicicleta sencera com un objecte, no camp a camp. Es pot destructurar en dos nivells:

La segona forma és correcta, però perd la referència a l'objecte complet i es torna il·legible amb molts camps. Al curs farem servir la primera: rebem bicicleta i, si cal, la destructurem al cos.

Qualsevol valor de JavaScript. Literalment qualsevol.

Vegem els casos que més es presten a confusió.

Escriure l'atribut solt equival a ={true}, igual que a HTML amb disabled o checked. Compte amb l'última línia: ometre la prop dona undefined, que és falsy però no és false. A la pràctica tots dos es comporten igual en una condició, però no són el mateix valor.

És la mateixa doble clau que ja vas veure a style={{ color: 'red' }}: les de fora obren una expressió JSX, les de dins són el literal d'objecte.

Passar funcions com a props és el mecanisme amb què un fill avisa el seu pare que alguna cosa ha passat. Aquí només cal que sàpigues que es pot fer i que la sintaxi és aquesta; el patró complet de comunicació fill → pare s'estudia a Elevar l'Estat, i els gestors d'esdeveniments a Gestió d'Esdeveniments.

Una prop pot contenir interfície. Això obre la porta a components molt flexibles:

Si el pare no passa una prop, aquesta arriba com a undefined. Perquè el component continuï funcionant, se li donen valors per defecte amb els paràmetres per defecte de JavaScript, directament a la desestructuració:

Un matís que causa sorpreses: el valor per defecte s'aplica només si la prop és undefined, no si és null, 0 o cadena buida.

En codi antic veuràs aquesta altra forma:

defaultProps està eliminat per als components de funció a partir de React 19. Si el trobes, és codi anterior i cal traduir-lo a paràmetres per defecte. En components de classe continua funcionant, perquè una classe no té una signatura on escriure els valors per defecte.

Hi ha una prop que no es passa com a atribut: tot el que escrius entre l'etiqueta d'obertura i la de tancament d'un component arriba a la prop children.

El component que la rep:

children és la base del patró de composició: escrius components que aporten una estructura o un comportament i deixes que qui els utilitza decideixi el contingut.

Un mateix Panell, dos continguts completament diferents. Sense children caldria inventar props per a cada cas possible, o duplicar el component.

Coses que convé saber sobre children:

• Pot ser qualsevol cosa: text, un element, diversos elements, un array, o res (undefined).
• children no es pot passar també com a atribut. Si escrius <Panell children="hola">adéu</Panell>, el contingut entre etiquetes guanya.
• Un component pot tenir diverses «zones» de contingut passant elements JSX per props amb nom (capcalera={<…/>}, peu={<…/>}). És el que de vegades s'anomena slots.

Aquest patró té molt més recorregut —contenidors genèrics, embolcalls, especialització de components— i s'aprofundeix a Composició vs Herència.

Aquesta és la regla més important de la lliçó, i no admet excepcions:

Un component mai ha de modificar les seves pròpies props. React funciona sota la premissa que un component, davant les mateixes props, produeix sempre el mateix resultat. Això s'anomena ser una funció pura.

Depèn de què estiguis mutant, i cap dels dos escenaris és bo:

El segon cas és el perillós: silenciós, difícil de depurar i capaç de produir «dades que canvien sense que ningú les pinti». A CicloUrbano, mutar bicicleta.estat dins de la targeta modificaria l'array bicicletes importat de domini.js per a tota l'aplicació.

• Si només necessites un valor transformat per pintar-lo, calcula una variable local. Això és perfectament correcte: el que està prohibit és escriure a la prop, no llegir-la ni derivar-ne.

• Si la dada ha de canviar de veritat, no és una prop: és estat, i ho veuràs a la propera lliçó. I si el canvi l'origina el fill però la dada pertany al pare, el fill avisa mitjançant una funció rebuda per props (04-01).

L'operador de propagació (...) permet passar totes les propietats d'un objecte com a props d'un cop:

I el component les rep com a props soltes:

També es pot combinar amb props explícites, i l'ordre mana: el que s'escriu després guanya.

És una eina còmoda de la qual s'abusa amb facilitat. Els inconvenients:

Els usos legítims són els components embolcall que reenvien props que no coneixen:

Aquí ...resta recull totes les props que no hem desestructurat (type, disabled, onClick…) i les reenvia. Aquest és el cas en què l'operador brilla.

Regla del curs: a CicloUrbano passarem l'objecte complet com una prop amb nom —bicicleta={bici}— en lloc de difondre'l. El contracte queda explícit i la signatura del component es llegeix sola.

Les props són el contracte públic del teu component. En JavaScript pur, res no impedeix passar un número on s'espera un objecte, així que convé deixar-ho escrit.

Costa trenta segons i resol el 80 % dels casos.

Abans que TypeScript es generalitzés, la comprovació de tipus a React es feia amb la llibreria prop-types, que valida en temps d'execució i només en desenvolupament, imprimint un avís a la consola:

Ho mencionem perquè el trobaràs en moltíssim codi existent, però avui està desaconsellat per a projectes nous: prop-types és una dependència extra, només avisa quan l'error ja ha passat i no ajuda l'editor.

És la resposta moderna: els tipus es comproven abans d'executar, l'editor autocompleta les props i renombrar un camp es propaga sol.

El tipatge seriós de components és el contingut de TypeScript amb React. Fins llavors, a CicloUrbano farem servir el nivell 1: un comentari clar a sobre de cada component reutilitzable.

És el moment de trencar el sostre. Convertirem TargetaBicicleta i EtiquetaEstat en components parametritzats i pintarem bicicletes diferents.

La classe es construeix amb una plantilla: estat--${estat} produeix estat--disponible, estat--alquilada o estat--mantenimiento, que són les classes CSS que vam definir a la lliçó 02-01. Tota la regla «quin color correspon a quin estat» viu ara en un sol lloc.

El que ha passat aquí, punt per punt:

• { bicicleta, nomEstacio = '…' }: destructuring a la signatura, amb un valor per defecte per a la prop opcional.
• preuFormatat: una variable derivada de la prop. Llegim la prop i calculem; no la modifiquem. toFixed(2) dona "2.50" i el replace el converteix al format decimal amb coma, "2,50".
• targeta-bicicleta--${bicicleta.tipus}: la classe de variant ja no està escrita a mà; surt de la dada. urbana, electrica o carga.
• <EtiquetaEstat estat={bicicleta.estat} />: TargetaBicicleta és pare d'EtiquetaEstat i li passa una prop. Les props descendeixen per l'arbre de nivell en nivell.

Sí, tres props numerades és una solució lletja, i ho és a propòsit: és el símptoma que falta una eina. Aquesta eina és recórrer un array amb map, i arriba a Llistes i Claus. Fixa't que el problema ja no és de props, sinó de repetició.

Desa i mira el navegador. Per fi:

Tres targetes diferents produïdes per un únic component. Aquest és el moment en què React comença a rendibilitzar-se: qualsevol canvi de disseny a la targeta s'escriu una vegada i s'aplica a totes tres.

Totes les fletxes apunten cap avall. Cap no puja. Això és el flux unidireccional de React.

• Passar números com a cadenes. preuHora="2.5" entrega el text "2.5", i qualsevol operació aritmètica o toFixed fallarà. Si no és text literal, va entre claus.
• Oblidar les claus de la desestructuració. function TargetaBicicleta(bicicleta) rep l'objecte props complet sota el nom bicicleta, així que bicicleta.model és undefined. La signatura correcta és function TargetaBicicleta({ bicicleta }).
• Mutar una prop de tipus objecte. bicicleta.estat = 'alquilada' no dona error i per això és tan perillós: modifiques la dada del pare sense que React ho sàpiga. Si la dada ha de canviar, és estat.
• Executar la funció en passar-la. alReservar={reservar()} crida reservar durant el render i passa el seu resultat. Sense parèntesis: alReservar={reservar}.
• Confiar en el valor per defecte davant d'un null. Només s'aplica amb undefined. Si el pare pot enviar null, gestiona-ho explícitament.
• Abusar de {...objecte}. Còmode d'escriure, car de mantenir. Reserva'l per a embolcalls que reenvien props desconegudes.
• Fer servir defaultProps en un component de funció. Eliminat a React 19. Fes servir paràmetres per defecte.
• Consell: la signatura és documentació. function TargetaBicicleta({ bicicleta, destacada = false }) diu més que qualsevol comentari. Cuida els noms de les props: són el vocabulari públic del component.
• Consell: si un component rep més de cinc o sis props, sospita. O fa massa coses, o diverses props haurien de viatjar agrupades en un objecte.
• Consell: inspecciona les props a DevTools. La pestanya Components mostra les props reals de cada instància. És la forma més ràpida de descobrir que estàs passant undefined.

Converteix TargetaEstacio (creada a la lliçó 01-03 amb dades fixes) en un component parametritzat. Ha de rebre una prop estacio amb la forma del domini.js i una prop opcional bicicletesEnEstacio (número, per defecte 0), i mostrar el nom, el barri, el total de places i el nombre de bicicletes. Després utilitza'l a App.jsx per pintar les tres estacions de CicloUrbano, escrivint-les una a una.

Crea el component Panell descrit a l'apartat 6 (src/components/Panell.jsx), amb props titol (cadena, obligatòria) i children. Afegeix-hi una prop opcional peu que admeti un element JSX i es pinti sota el contingut si es proporciona. Després utilitza'l dues vegades a App.jsx: una embolicant la llista de bicicletes i una altra amb un avís de text.

Pista: per pintar el peu només si existeix, recorda que a JSX {undefined} no pinta res.

Aquest component té quatre errors relacionats amb les props. Troba'ls, explica què provoca cadascun i escriu la versió corregida.

Solució 1.

Fixa't en placesLliures: és un valor derivat de les props, calculat a cada render. No és una prop ni cal desar-lo enlloc. Aquesta distinció entre el que es desa i el que es calcula serà central a la propera lliçó.

Solució 2.

El mateix component embolica una llista completa en un cas i un paràgraf en l'altre: això és el que aporta children. L'expressió {peu && <div…>} és renderitzat condicional, que s'estudia a fons a Renderitzat Condicional; aquí n'hi ha prou de saber que si peu és undefined, no es pinta res.

Solució 3.

Els quatre errors:

1. Signatura incorrecta. function FilaBicicleta(bicicleta, preuHora = 0) tracta les props com dos paràmetres diferents. React sempre passa un únic objecte com a primer argument, així que bicicleta acaba sent l'objecte props sencer i preuHora no rep mai res: es queda en el seu valor per defecte, 0. Cal desestructurar: ({ bicicleta, preuHora = 0 }).
2. Mutació d'una prop. bicicleta.model = bicicleta.model.toUpperCase() modifica l'objecte del domini.js, afectant tota l'aplicació i sense disparar cap render. Cal calcular una variable nova.
3. Número passat com a cadena. preuHora="2.5" entrega el text "2.5"; "2.5".toFixed no existeix i llança TypeError. Ha de ser preuHora={2.5}.
4. Contracte incoherent. preuHora ja ve dins de l'objecte bicicleta; passar-lo a més per separat duplica la font de veritat i permet que les dues es contradiguin. S'ha de llegir de la bicicleta.

Versió corregida:

Les props són el mecanisme amb què un component rep dades de l'exterior, i amb elles el catàleg de CicloUrbano ha deixat de ser una maqueta: una sola TargetaBicicleta pinta ara tres bicicletes diferents amb el seu model, el seu preu, la seva variant de color i el seu distintiu d'estat. Saps passar-les com a atributs —text entre cometes, tota la resta entre claus—, rebre-les amb destructuring a la signatura, donar-los valors per defecte amb paràmetres per defecte (i que defaultProps ja no existeix per a funcions a React 19), passar qualsevol tipus de valor —inclosos objectes, funcions i elements JSX— i utilitzar la prop especial children per construir contenidors com Panell que embolcallen contingut arbitrari.

I tens clara la regla que sosté tot el model: les props són de només lectura. Un component les llegeix i en deriva valors, però mai les escriu. El flux de dades baixa per l'arbre i no puja, cosa que fa que rastrejar l'origen de qualsevol dada sigui sempre possible. També saps que difondre props amb {...objecte} és còmode però esborra el contracte, i que aquest contracte convé documentar-lo, avui amb un comentari i en el futur amb TypeScript.

Queda una pregunta oberta, i és grossa: si les props vénen de fora i no es poden modificar, com canvia alguna cosa en una aplicació React? Quan l'usuari tria un filtre, reserva una bicicleta o prem un botó, alguna cosa ha de canviar i provocar un nou render. Aquesta cosa és l'estat: la memòria pròpia d'un component, la dada que sí que pot canviar i que, en fer-ho, dispara el cicle de renderitzat que vas estudiar a 01-05. És el tema de la propera lliçó: Estat: Gestió de l'Estat del Component.