El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència
HOME Els meus cursos Finalitzats
◄ Anterior
◄

Components Funcionals vs de Classe

Següent ►
►

Tots els components que has escrit fins ara són funcions: Benvinguda, Capcalera, TargetaBicicleta, EtiquetaEstat. És la forma que faràs servir durant la resta del curs i la que recomana oficialment l'equip de React. Però React té més d'una dècada d'història, i durant bona part d'aquesta l'única manera d'escriure un component amb memòria pròpia era fer servir una classe. Això vol dir que tan bon punt t'incorporis a un projecte amb recorregut —o obris una resposta de Stack Overflow del 2018, o llegeixis el codi d'una llibreria veterana— et trobaràs class TargetaBicicleta extends React.Component, this.props, render() i bind. Aquesta lliçó té un objectiu molt concret i molt pràctic: que sàpigues llegir aquest codi amb soltesa, entendre què fa cada peça i traduir-lo mentalment a la sintaxi moderna. No escriuràs components de classe nous; deixaràs de tenir-los por.

Contingut

  1. Dues sintaxis per a la mateixa idea
  2. Anatomia d'un component de classe: TargetaBicicleta reescrita
  3. this.props: les dades que arriben de fora
  4. constructor, this.state i setState
  5. El problema del this i per què apareix tant bind
  6. Taula comparativa completa
  7. Per què React recomana funcions des del 2019
  8. Què continuen aportant les classes avui
  9. Traduir de classe a funció: taula d'equivalències
  10. Com enfrontar-te a codi heretat a la pràctica

  1. Dues sintaxis per a la mateixa idea

Comencem pel més essencial: per a React totes dues formes són idèntiques. Totes dues produeixen elements, totes dues s'utilitzen com <TargetaBicicleta />, totes dues participen en la reconciliació exactament igual i totes dues poden conviure en el mateix arbre. Una funció pot renderitzar una classe i una classe pot renderitzar una funció sense cap problema.

La diferència està en com es declaren i com accedeixen a les seves capacitats.

// Component de funció: una funció que retorna JSX
function Benvinguda() {
  return <h1>CicloUrbano</h1>;
}
// Component de classe: una classe amb un mètode render() que retorna JSX
import { Component } from 'react';

class Benvinguda extends Component {
  render() {
    return <h1>CicloUrbano</h1>;
  }
}

Tots dos s'utilitzen igual des de fora:

<Benvinguda />

Qui escriu <Benvinguda /> no sap —ni necessita saber— quina de les dues formes hi ha al darrere. Aquesta és la raó per la qual un projecte pot migrar de classes a funcions component a component, sense big bang.

Un apunt de vocabulari: veuràs les funcions anomenades components funcionals, components de funció o, en documentació antiga, components sense estat (stateless functional components). Aquest darrer terme va quedar obsolet el 2019: des dels hooks, una funció pot tenir estat perfectament.

  1. Anatomia d'un component de classe: TargetaBicicleta reescrita

Agafarem la TargetaBicicleta del catàleg de CicloUrbano i l'escriurem com a classe. Aquest codi és material de lectura, no un model a imitar.

// src/components/TargetaBicicleta.jsx  — VERSIÓ DE CLASSE (codi heretat)
import { Component } from 'react';
import EtiquetaEstat from './EtiquetaEstat.jsx';

class TargetaBicicleta extends Component {
  render() {
    return (
      <article className="targeta-bicicleta targeta-bicicleta--urbana">
        <h3>
          Urbana Clàssica <EtiquetaEstat />
        </h3>
        <p>Tipus: urbana</p>
        <p>Estació: Plaça Major</p>
        <p>
          <strong>2,50 € / hora</strong>
        </p>
      </article>
    );
  }
}

export default TargetaBicicleta;

Peça a peça:

Element Què significa
import { Component } from 'react' Porta la classe base. També es veu com import React from 'react' + extends React.Component
class TargetaBicicleta extends Component Declara la classe heretant de la base de React, que aporta this.props, this.state i setState
render() Mètode obligatori. React el crida per saber què pintar. És l'equivalent exacte al cos de la funció
return (...) Retorna el JSX. Les mateixes regles de sempre: arrel única, className, autotancament
export default TargetaBicicleta Idèntic a la versió de funció

L'equivalència mental clau: render() és al component de classe el que el cos de la funció és al component de funció. Tot el que hi havia al return de la teva funció, en una classe és dins de render().

Compte amb un matís: extends Component és el que converteix una classe corrent en un component de React. Sense aquesta herència, React no sap què fer-ne i falla en renderitzar.

  1. this.props: les dades que arriben de fora

Les props són les dades que un component rep del seu pare. Són el tema complet de la propera lliçó, Props; aquí només ens interessa la diferència de sintaxi d'accés, perquè és el que més desorienta en llegir codi antic.

En una funció, les props arriben com a paràmetre:

function TargetaBicicleta(props) {
  return <h3>{props.bicicleta.model}</h3>;
}

En una classe, les props estan a this.props:

class TargetaBicicleta extends Component {
  render() {
    return <h3>{this.props.bicicleta.model}</h3>;
  }
}

Aquí tens la versió de classe completa, ja parametritzada amb una bicicleta del domini.js:

// VERSIÓ DE CLASSE amb props (codi heretat)
import { Component } from 'react';

class TargetaBicicleta extends Component {
  render() {
    // Patró habitual: extreure les props al principi de render()
    // per no repetir "this.props." en tot el JSX
    const { bicicleta } = this.props;

    return (
      <article className={`targeta-bicicleta targeta-bicicleta--${bicicleta.tipus}`}>
        <h3>{bicicleta.model}</h3>
        <p>Tipus: {bicicleta.tipus}</p>
        <p>Estat: {bicicleta.estat}</p>
        <p>
          <strong>{bicicleta.preuHora.toFixed(2)} € / hora</strong>
        </p>
      </article>
    );
  }
}

export default TargetaBicicleta;

Aquest const { bicicleta } = this.props; a la primera línia de render() és un patró que veuràs constantment en codi heretat. No és màgia: és destructuring d'ES6 aplicat a this.props.

Dues regles comunes a totes dues sintaxis, que convé subratllar ja:

  • Les props són de només lectura en tots dos casos. Ni props.bicicleta = … ni this.props.bicicleta = … són vàlids. React avisa i el flux unidireccional es trenca.
  • El nom props és una convenció, no una paraula reservada del llenguatge. En una funció podries anomenar el paràmetre com volguessis; en una classe, en canvi, this.props sí que és un nom fix que imposa la classe base.

  1. constructor, this.state i setState

L'estat és la memòria interna d'un component i és el tema de la lliçó Estat. Amb classes, es gestiona amb tres peces.

// PanellReserva com a classe (codi heretat)
import { Component } from 'react';

class PanellReserva extends Component {
  // 1. El constructor inicialitza l'estat
  constructor(props) {
    super(props);            // OBLIGATORI abans d'utilitzar this
    this.state = {
      hores: 1
    };
  }

  // 2. Un mètode que actualitza l'estat
  afegirHora() {
    this.setState({ hores: this.state.hores + 1 });
  }

  render() {
    // 3. La lectura de l'estat és this.state
    return (
      <section className="panell-reserva">
        <p>Hores de lloguer: {this.state.hores}</p>
      </section>
    );
  }
}

export default PanellReserva;

Les tres peces, en detall:

  • constructor(props) + super(props). El constructor és l'únic lloc on l'estat s'assigna directament amb this.state = {…}. La crida a super(props) és obligatòria: sense ella, this encara no existeix i JavaScript llança un error. És un dels errors clàssics en escriure classes.
  • this.state. Un objecte únic que conté tot l'estat del component. És una diferència important respecte a la sintaxi moderna, on es declara un tros d'estat independent per a cada dada.
  • this.setState({…}). L'única forma vàlida d'actualitzar. Mai this.state.hores = 5: això muta l'objecte sense avisar React, de manera que no es dispara cap render i la pantalla es queda desactualitzada. A més, setState fa una fusió superficial: l'objecte que li passes es barreja amb l'estat existent, i les claus que no esmentes es conserven.
// Si l'estat és { hores: 1, tipus: 'urbana' }
this.setState({ hores: 3 });
// L'estat queda { hores: 3, tipus: 'urbana' }  ->  'tipus' es conserva sol

Aquesta fusió automàtica és una diferència real de comportament respecte a la sintaxi moderna, on cada actualització reemplaça el valor complet. Tingues-ho present en traduir codi: és font d'errors subtils.

  1. El problema del this i per què apareix tant bind

Aquest és el punt on les classes es van guanyar la seva mala fama. En JavaScript, el valor de this dins d'un mètode depèn de com es crida el mètode, no d'on es defineix. Quan passes un mètode com a gestor d'esdeveniment, es crida «solt» i perd el vincle amb la instància.

// TRENCAT: en polsar, this és undefined i esclata amb
// "Cannot read properties of undefined (reading 'setState')"
class PanellReserva extends Component {
  constructor(props) {
    super(props);
    this.state = { hores: 1 };
  }

  afegirHora() {
    this.setState({ hores: this.state.hores + 1 });  // <- this no és la instància
  }

  render() {
    return <button onClick={this.afegirHora}>Afegir hora</button>;
  }
}

Històricament hi va haver tres solucions, i les veuràs totes tres en codi real:

// Solució A (la més comuna en codi antic): bind al constructor
constructor(props) {
  super(props);
  this.state = { hores: 1 };
  this.afegirHora = this.afegirHora.bind(this);   // <- la línia reveladora
}
// Solució B: funció fletxa al JSX
<button onClick={() => this.afegirHora()}>Afegir hora</button>
// Solució C (la més moderna dins de les classes): camp de classe amb fletxa
afegirHora = () => {
  this.setState({ hores: this.state.hores + 1 });
};

Les funcions fletxa no tenen this propi: el prenen de l'àmbit on es van definir, que aquí és la instància. Per això B i C funcionen.

Quan obris un fitxer i vegis un constructor amb quatre línies this.algo = this.algo.bind(this), ja saps exactament què estàs mirant: codi de classe resolent el problema del this. En els components de funció aquest problema senzillament no existeix, perquè no hi ha this enlloc. És una de les simplificacions més grans que va portar la sintaxi moderna.

  1. Taula comparativa completa

Aspecte Component de funció Component de classe
Declaració function X() { … } class X extends Component { render() { … } }
Verbositat Mínima: per a un component senzill, 3 línies Alta: classe + render() + sovint constructor
this No existeix. Res a enllaçar Central i problemàtic: exigeix bind o fletxes
Accés a les props Paràmetre: props.bicicleta o destructuring a la signatura this.props.bicicleta
Accés a l'estat Un valor independent per cada dada Un únic objecte this.state
Actualitzar l'estat Funció actualitzadora per cada dada; reemplaça el valor this.setState; fusiona superficialment
Efectes secundaris i cicle de vida Hooks (Mòdul 5) Mètodes de cicle de vida (04-03)
Reutilitzar lògica Hooks personalitzats: composició senzilla HOC i render props: molta més cerimònia i imbricació
Rendiment Equivalent. La diferència pràctica és menyspreable; les funcions són una mica més lleugeres de transpilar i permeten optimitzacions futures del compilador Equivalent
Mida del codi Menor: menys text per a la mateixa funcionalitat Major
Documentació oficial És l'única forma que s'ensenya des del 2023 Apareix en una secció d'API heretada
Suport de la comunitat Totes les llibreries modernes assumeixen funcions Compatible, però cada vegada menys exemples nous
Continua suportat a React 19? Sí, és la forma recomanada Sí, no està previst eliminar-lo
Quan utilitzar-lo Sempre en codi nou Només en mantenir codi existent i en límits d'error

  1. Per què React recomana funcions des del 2019

El febrer del 2019, React 16.8 va introduir els hooks, i amb ells les funcions van deixar d'estar limitades: podien tenir estat, executar efectes i accedir al context. A partir d'aquell moment, l'equip de React va desaconsellar les classes per a codi nou. Els motius, per ordre d'importància:

  1. Reutilitzar lògica amb estat era molt difícil. Amb classes, compartir comportament entre components obligava a patrons com els higher-order components o les render props, que produïen arbres amb cinc o sis capes d'embolcalls sense sentit visual (el que es coneixia com a wrapper hell). Els hooks personalitzats resolen això amb una simple crida a funció.

  2. La lògica relacionada quedava dispersa. En una classe, subscriure's a alguna cosa i cancel·lar la subscripció vivien en mètodes de cicle de vida diferents i allunyats entre si, mentre que un mateix mètode barrejava assumptes que no tenien res a veure. Amb hooks, cada preocupació s'agrupa en el seu propi bloc.

  3. El this confonia les persones i les màquines. A més del problema d'enllaç que has vist, this complica les optimitzacions automàtiques: és més difícil analitzar estàticament una classe que una funció.

  4. Menys soroll, menys superfície d'error. Comparar les dues versions de TargetaBicicleta és eloqüent: la de classe necessita un import extra, una declaració de classe, un mètode render i una indentació addicional per expressar exactament la mateixa idea.

Molt important: les classes no estan obsoletes ni es preveu eliminar-les. L'equip de React ha estat explícit que no hi ha plans de retirar-les i que el codi antic continuarà funcionant. No hi ha cap urgència per migrar un projecte que funciona. El que sí que hi ha és una recomanació clara: tot el que sigui nou, amb funcions.

  1. Què continuen aportant les classes avui

Una única cosa, i convé tenir-la identificada amb precisió:

Els límits d'error (error boundaries) només es poden escriure amb components de classe.

Un límit d'error és un component que captura els errors llançats pels seus fills durant el render i mostra una interfície alternativa en lloc de deixar que l'aplicació sencera es quedi en blanc. Necessita els mètodes static getDerivedStateFromError i componentDidCatch, que no tenen equivalent en forma de hook. És el tema de la lliçó Límits d'Error, i allà escriuràs l'únic component de classe «de veritat» del curs.

A la pràctica això no canvia res de la teva manera de treballar, per dues raons: els límits d'error són un o dos components en tota una aplicació, i llibreries com react-error-boundary ja els encapsulen perquè ni tan sols hagis d'escriure'ls.

Fora d'aquest cas, no queda cap capacitat exclusiva de les classes. Tota la resta —estat, efectes, context, referències al DOM, memoïtzació— té el seu equivalent en hooks.

  1. Traduir de classe a funció: taula d'equivalències

Aquesta taula és el teu diccionari per llegir codi heretat. Encara no cal que dominis la columna de la dreta: cada hook s'estudia a fons al Mòdul 5. Fes-la servir com a referència de traducció.

En una classe En una funció
class X extends Component function X()
El cos de render() El cos de la funció
this.props.bicicleta El paràmetre props.bicicleta, o { bicicleta } a la signatura
this.state = { hores: 1 } al constructor useState(1) per a la dada hores
this.state.hores La variable hores
this.setState({ hores: 3 }) La funció actualitzadora de hores
Fusió automàtica de l'estat No n'hi ha: cada dada és independent
constructor per inicialitzar La inicialització va a la mateixa crida a useState
this.afegirHora.bind(this) Res. El problema desapareix
componentDidMount useEffect amb la llista de dependències buida
componentDidUpdate useEffect amb dependències
componentWillUnmount La funció de neteja que retorna useEffect
shouldComponentUpdate React.memo (08-02)
this.meuNode amb createRef useRef (05-03)
static contextType useContext (05-04)
HOC o render props per compartir lògica Un hook personalitzat (05-06)
static getDerivedStateFromError Sense equivalent: requereix classe

Aquí tens la traducció completa de PanellReserva, perquè vegis la reducció d'un cop d'ull:

// ABANS: classe (codi heretat)
import { Component } from 'react';

class PanellReserva extends Component {
  constructor(props) {
    super(props);
    this.state = { hores: 1 };
    this.afegirHora = this.afegirHora.bind(this);
  }

  afegirHora() {
    this.setState({ hores: this.state.hores + 1 });
  }

  render() {
    return (
      <section className="panell-reserva">
        <p>Hores de lloguer: {this.state.hores}</p>
        <button onClick={this.afegirHora}>Afegir hora</button>
      </section>
    );
  }
}

export default PanellReserva;
// DESPRÉS: funció amb hooks (la forma de la resta del curs)
import { useState } from 'react';

function PanellReserva() {
  const [hores, setHores] = useState(1);

  return (
    <section className="panell-reserva">
      <p>Hores de lloguer: {hores}</p>
      <button onClick={() => setHores(hores + 1)}>Afegir hora</button>
    </section>
  );
}

export default PanellReserva;

Vint-i-cinc línies contra dotze, sense this, sense constructor i sense bind. I encara no cal entendre com funciona useState per dins per apreciar la diferència: ho veuràs a la propera lliçó d'estat i a fons al Mòdul 5.

  1. Com enfrontar-te a codi heretat a la pràctica

Un guió sensat quan aterres en un projecte amb classes:

flowchart TD
    A[Trobo un component de classe] --> B{Ho he de canviar?}
    B -- No --> C[Deixa'l. Funciona igual de bé]
    B -- Sí --> D{El canvi és petit?}
    D -- Sí --> E[Fes-ho a la mateixa classe.<br/>No barregis arranjament i migració]
    D -- No, és una reescriptura --> F{Hi ha proves que ho cobreixin?}
    F -- Sí --> G[Migra a funció i recolza't en les proves]
    F -- No --> H[Escriu primer les proves.<br/>Després migra]

Tres consells de camp:

  • Migrar per migrar no aporta valor. Un component de classe estable, provat i que ningú toca no és deute tècnic: és codi que funciona. Prioritza migrar aquells on hagis de treballar de totes maneres.
  • No barregis migració i canvi funcional en el mateix commit. Si alguna cosa es trenca, no sabràs si va ser la traducció o la funcionalitat nova.
  • Compte amb la fusió de setState. És la trampa número u en traduir: un this.setState({ a: 1 }) conserva b sense dir-ho, i la versió amb hooks separats s'ha d'escriure tenint això en compte.

I quant a CicloUrbano: la resta del curs s'escriu íntegrament amb components de funció. L'única excepció serà el límit d'error de la lliçó 04-05, on la classe és obligatòria pel disseny de React. La versió de classe de TargetaBicicleta que has llegit aquí es queda com a exercici de lectura; el teu projecte conserva la versió de funció.

Errors Comuns i Consells

  • Oblidar super(props) al constructor. L'error és Must call a super constructor in derived class before accessing 'this'. Si escrius una classe i no defineixes constructor propi, no hi ha problema; si el defineixes, super(props) va sempre a la primera línia.
  • Mutar this.state directament. this.state.hores = 5 no llança cap error visible, però React no se n'assabenta i la pantalla no canvia. Sempre this.setState.
  • Llegir this.state just després de setState i esperar el valor nou. Les actualitzacions s'agrupen i s'apliquen després; a la línia següent encara veuràs el valor antic. És el mateix comportament que estudiaràs amb la sintaxi moderna a Estat.
  • Escriure el render() amb un nom diferent. El mètode s'ha de dir exactament render. Un Render() o un renderitzar() produeix l'error Objects are not valid as a React child o directament una pantalla buida.
  • Convertir una classe en funció copiant només el cos de render(). Cal revisar també el constructor, els mètodes auxiliars, els bind i els mètodes de cicle de vida. El render() és només una part.
  • Consell: quan vegis this. en un fitxer de React, ja saps què tens al davant. És el marcador infal·lible d'un component de classe.
  • Consell: no t'aprenguis la sintaxi de classe, aprèn-te la taula de traducció. L'objectiu és llegir, no produir.

Exercicis

Exercici 1

Tradueix aquest component de classe de CicloUrbano a un component de funció. No necessites hooks: no té estat.

import { Component } from 'react';

class TargetaEstacio extends Component {
  render() {
    const { estacio } = this.props;
    return (
      <article className="targeta-estacio">
        <h3>{estacio.nom}</h3>
        <p>Barri: {estacio.barri}</p>
        <p>Places: {estacio.places}</p>
      </article>
    );
  }
}

export default TargetaEstacio;

Exercici 2

El component de classe següent falla en polsar el botó amb el missatge Cannot read properties of undefined (reading 'setState'). Explica amb precisió per què passa i dona dues solucions diferents dins de la mateixa sintaxi de classe.

import { Component } from 'react';

class DisponibilitatEstacio extends Component {
  constructor(props) {
    super(props);
    this.state = { lliures: 12 };
  }

  ocuparPlaça() {
    this.setState({ lliures: this.state.lliures - 1 });
  }

  render() {
    return (
      <section>
        <p>Places lliures a Plaça Major: {this.state.lliures}</p>
        <button onClick={this.ocuparPlaça}>Ocupar una plaça</button>
      </section>
    );
  }
}

Exercici 3

Un company afirma: «Reescriurem els trenta components de classe del projecte a funcions, perquè les classes estan obsoletes i a més rendeixen pitjor.» Avalua les dues afirmacions tècniques i proposa una estratègia raonable. Indica també si hi ha algun component que no es pugui migrar.

Solucions

Solució 1.

// src/components/TargetaEstacio.jsx
function TargetaEstacio({ estacio }) {
  return (
    <article className="targeta-estacio">
      <h3>{estacio.nom}</h3>
      <p>Barri: {estacio.barri}</p>
      <p>Places: {estacio.places}</p>
    </article>
  );
}

export default TargetaEstacio;

Els canvis, un a un:

S'elimina Se substitueix per
import { Component } from 'react' Res: una funció no necessita res de React per existir
class … extends Component function TargetaEstacio(…)
render() { … } El cos de la funció
const { estacio } = this.props; El destructuring directament a la signatura: ({ estacio })

D'onze línies de cerimònia passem a zero. El JSX és idèntic, perquè el JSX mai no va dependre de la sintaxi del component.

Solució 2.

Per què falla. A render(), this.ocuparPlaça no es crida: es passa com a referència a onClick. Quan React invoca aquest gestor més tard, ho fa com una funció solta, sense cap objecte davant del punt. En una classe de JavaScript (que s'executa en mode estricte) el this d'una funció invocada així és undefined, de manera que this.setState intenta llegir una propietat d'undefined i llança l'error.

Solució A: enllaçar al constructor.

constructor(props) {
  super(props);
  this.state = { lliures: 12 };
  this.ocuparPlaça = this.ocuparPlaça.bind(this);
}

Solució B: declarar el mètode com a camp de classe amb funció fletxa.

ocuparPlaça = () => {
  this.setState({ lliures: this.state.lliures - 1 });
};

Una tercera opció seria embolicar la crida al JSX: onClick={() => this.ocuparPlaça()}. Funciona, però crea una funció nova a cada render, cosa que té implicacions que veuràs al Mòdul 8.

En un component de funció aquest problema no es pot donar, perquè no hi ha this al qual enllaçar res.

Solució 3.

«Les classes estan obsoletes»: fals. No estan marcades com a obsoletes ni hi ha plans d'eliminar-les. Estan desaconsellades per a codi nou, que és una cosa diferent: el codi existent continuarà funcionant a React 19 i a les versions següents.

«Rendeixen pitjor»: fals a la pràctica. La diferència de rendiment entre totes dues sintaxis és menyspreable i mai no serà la causa d'un problema real. Els colls d'ampolla vénen de renders innecessaris, llistes enormes o feina pesada al render, no de la forma de declarar el component. I aquestes causes s'ataquen igual amb totes dues sintaxis.

Estratègia raonable:

  1. Congelar el creixement: tot component nou s'escriu com a funció. Amb això la proporció de codi heretat només pot baixar.
  2. Migració oportunista: quan calgui tocar un component de classe per un motiu funcional, es migra en aquell moment, en un commit separat del canvi funcional.
  3. Prioritzar pel dolor real: primer els components amb bind per tot arreu, amb lògica duplicada entre componentDidMount i componentDidUpdate, o embolicats en diversos HOC. Aquí la migració es paga sola.
  4. Cobrir amb proves abans de migrar els components crítics (Mòdul 9).
  5. Mai migrar «en bloc» sense necessitat. Trenta reescriptures simultànies són trenta oportunitats d'introduir una regressió a canvi de cap valor per a l'usuari.

Components que no es poden migrar: els límits d'error. static getDerivedStateFromError i componentDidCatch no tenen equivalent en hooks, així que aquests components es queden com a classes (o es delega en una llibreria que les encapsuli). S'estudien a Límits d'Error.

Conclusió

Ja saps llegir les dues formes d'escriure un component a React. Un component de classe estén Component, obliga a implementar render(), accedeix a les dades amb this.props, guarda la seva memòria en un únic objecte this.state que s'actualitza amb this.setState —amb fusió superficial— i arrossega el problema del this, que explica els bind que poblen els seus constructors. Un component de funció fa el mateix sense classe, sense render(), sense constructor i sense this, amb menys codi i amb hooks per a tot allò que les classes resolien amb mètodes de cicle de vida.

També tens el perquè del canvi: els hooks, el 2019, van eliminar l'únic avantatge que li quedava a les classes —l'estat— i van resoldre molt millor el problema de reutilitzar lògica. I tens l'excepció ben delimitada: els límits d'error continuen exigint una classe, i els veuràs a 04-05. Fora d'això, tota la resta del curs —i tot el que escriguis en un projecte modern— serà un component de funció.

Amb les dues sintaxis clares, tornem al sostre que vam deixar pendent a la lliçó anterior: les nostres tres TargetaBicicleta continuen mostrant la mateixa bicicleta perquè les dades estan escrites dins del component. A la propera lliçó, Props: Passant Dades als Components, obrirem aquest component a l'exterior: aprendràs a parametritzar-lo, a destructurar les seves props a la signatura, a donar-los valors per defecte, a embolicar contingut amb children i a entendre per què les props són de només lectura. A partir d'aquí, el catàleg de CicloUrbano deixarà de ser una maqueta i començarà a mostrar dades de veritat.

◄ Anterior
◄
Següent ►
►

Curs de React

Mòdul 1: Introducció a React

Mòdul 2: Components de React

Mòdul 3: Treballar amb Esdeveniments

Mòdul 4: Conceptes Avançats de Components

Mòdul 5: Hooks de React

Mòdul 6: Enrutament a React

Mòdul 7: Gestió de l'Estat

Mòdul 8: Optimització del Rendiment

Mòdul 9: Proves a React

Mòdul 10: Temes Avançats

Mòdul 11: Projecte: Construir una Aplicació Completa

El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència
© Copyright 2026. Tots els drets reservats