Les dues lliçons anteriors han deixat <task-card> amb una peça de lògica autocontinguda però atrapada dins de la seva pròpia classe: un temporitzador que arrenca a connectedCallback, s'atura a disconnectedCallback, i un càlcul (_calcularSiCercaDeVencer) que tots dos comparteixen. Funciona perfectament per a <task-card>, però si demà <task-board> necessités mostrar, per exemple, un resum amb el nombre de tasques a prop de la seva data límit, aquesta mateixa lògica hauria de copiar-se i enganxar-se en una segona classe, amb el risc que les dues còpies acabin divergint amb el temps. Aquesta lliçó presenta l'eina que Lit ofereix específicament per a aquest problema: els controladors reactius, objectes reutilitzables capaços d'enganxar-se al cicle de vida de qualsevol component sense necessitat d'heretar-hi.

1. El problema: lògica amb cicle de vida propi, atrapada en una classe
2. Què és un ReactiveController
3. La interfície d'un controlador: hostConnected, hostDisconnected, hostUpdate, hostUpdated
4. addController: registrant un controlador al seu host
5. Extraient el temporitzador de <task-card> a un controlador reutilitzable
6. Usant el controlador des de <task-card>
7. Per què un controlador i no simplement una funció auxiliar
8. Tancament: controladors en front de mixins

La lògica afegida a la lliçó 06-01 té una característica particular que la distingeix d'un simple mètode auxiliar: necessita enganxar-se al cicle de vida del component que la usa. No n'hi ha prou d'extreure _calcularSiCercaDeVencer a una funció independent (això ja seria trivial, sense necessitat de cap concepte nou); el problema de fons és que el temporitzador en si —quan arrenca, quan s'atura— depèn de quan <task-card> es connecta i es desconnecta del DOM, i aquesta dependència del cicle de vida és, precisament, el que fa que copiar i enganxar aquesta lògica en un segon component sigui tan temptador com propens a errors: qualsevol correcció futura (per exemple, ajustar el marge de "a prop de vèncer" de 24 hores a 48) hauria d'aplicar-se en totes les còpies per separat.

Un ReactiveController és, en la seva forma més simple, un objecte corrent de JavaScript (no necessita heretar de cap classe de Lit) que implementa una o diverses d'un petit conjunt de funcions amb noms reservats, i que es registra explícitament sobre un component Lit (anomenat, en aquesta relació, el seu host) per rebre avisos en els mateixos moments clau del cicle de vida que ja s'han estudiat a les lliçons anteriors d'aquest mòdul.

La idea central, i la que resol el problema de l'apartat 1, és que un mateix controlador —una mateixa classe de JavaScript— es pot registrar sobre tants hosts diferents com calgui, cada un amb la seva pròpia instància del controlador, sense que cap necessiti heretar d'una classe base comuna ni duplicar codi: el controlador encapsula tant l'estat (per exemple, l'identificador de l'interval actiu) com el comportament (arrencar-lo, aturar-lo, calcular el resultat), i el component que l'usa es limita a mantenir una referència al controlador i a llegir, des del seu render(), la dada que el controlador exposa.

Un controlador pot implementar qualsevol d'aquests mètodes, tots opcionals, i Lit els crida automàticament en el moment corresponent del cicle de vida del seu host:

Aquesta correspondència no és casual: els controladors reactius estan dissenyats deliberadament com una via alternativa per enganxar-se als mateixos punts exactes del cicle de vida que ja s'han estudiat com a mètodes de la pròpia classe del component, amb la diferència que, en lloc de viure mesclats dins de la classe del component, viuen en un objecte a part, reutilitzable de manera independent.

Perquè un controlador comenci a rebre aquests avisos, el seu host —qualsevol LitElement, sense necessitat de cap configuració addicional— l'ha de registrar explícitament amb this.addController(controlador), normalment dins del constructor del component:

És habitual, com en aquest exemple, que el propi constructor del controlador rebi el host com a argument i cridi ell mateix host.addController(this) internament, de manera que instanciar el controlador i registrar-lo sigui un únic pas, tal com es veurà a l'apartat següent. A partir d'aquest registre, Lit s'encarrega d'invocar els mètodes de la taula anterior en el moment adequat, exactament igual que si fossin mètodes de la pròpia classe del component.

Amb la interfície ja clara, la lògica de la lliçó 06-01 es trasllada, gairebé sense canvis conceptuals, a una classe independent:

Diversos detalls distingeixen aquest codi de l'original de la lliçó 06-01, i tots responen a la mateixa necessitat: fer-lo reutilitzable per qualsevol host, no només per <task-card>.

• El constructor guarda una referència al host rebut com a paràmetre, i crida ell mateix host.addController(this): qui usi aquest controlador no necessita recordar-se de cridar addController per separat, n'hi ha prou d'instanciar-lo passant-li this (el propi component) com a argument.
• El marge de "a prop de vèncer" (margenMs) i la freqüència de comprovació (intervaloMs) s'han convertit en paràmetres configurables, amb valors per defecte raonables, en lloc d'estar fixats directament al codi com a la lliçó 06-01: això permet que un futur segon host usi, per exemple, un marge de 48 hores sense haver de copiar i modificar el controlador.
• El controlador llegeix this.host.fechaLimite directament, assumint que qualsevol host que l'usi exposarà una propietat amb aquest nom. Aquesta és l'única suposició que el controlador fa sobre el seu host, i convé documentar-la amb claredat: un controlador reutilitzable sempre necessita algun contracte mínim sobre allò que el seu host li ha d'oferir.
• Fonamental: en lloc d'assignar directament una propietat reactiva del host (this.host.cercaDeVencer = ..., com feia <task-card> a la lliçó 06-01), el controlador guarda el seu propi resultat en un camp propi (this.cercaDeVencer, en el propi controlador, no en el host) i crida explícitament this.host.requestUpdate() per demanar a Lit que torni a executar render(). El controlador no necessita declarar cap propietat reactiva de Lit per al seu propi estat intern; li n'hi ha prou amb requestUpdate(), exactament el mateix mecanisme de baix nivell estudiat al mòdul 2, per provocar una actualització cada vegada que el seu resultat canviï.

Amb el controlador ja extret, <task-card> es simplifica notablement: desapareixen connectedCallback, disconnectedCallback i _calcularSiCercaDeVencer de la lliçó 06-01, substituïts per una única instància del controlador.

Val la pena notar que cercaDeVencer ja no existeix com a propietat d'estat de <task-card> (ha desaparegut de static properties): ara viu exclusivament dins del controlador, i render() la llegeix directament com this._contadorTiempo.cercaDeVencer. <task-card> ni tan sols necessita saber que, internament, aquest valor s'actualitza mitjançant un setInterval; només necessita saber que el controlador exposa una propietat cercaDeVencer llegible en qualsevol moment, i que Lit tornarà a executar render() automàticament cada vegada que aquest valor canviï, gràcies al requestUpdate() que el propi controlador invoca.

Si més endavant <task-board> necessités mostrar quantes tasques estan a prop de vèncer, podria instanciar el seu propi ContadorTiempoRestanteController per a cada tasca de this.tareas (o, més simple, reutilitzar el mateix càlcul agregant-lo des de diverses instàncies ja creades a cada <task-card>), sense duplicar ni una sola línia de la lògica del temporitzador: el controlador ja està escrit, provat i llest per usar-se en qualsevol host que exposi una propietat fechaLimite.

Cal preguntar-se per què fa falta un objecte amb aquesta interfície concreta, en lloc de limitar-se a extreure _calcularSiCercaDeVencer a una funció solta i importar-la on calgui. La resposta rau en allò que una funció solta no pot resoldre per si sola: el cicle de vida i l'estat que persisteix entre crides. Una funció auxiliar sense estat propi serviria perfectament per al càlcul puntual (_calcularSiCercaDeVencer(fechaLimite) ja ho era, de fet, des de la lliçó 06-01), però no pot, per si mateixa, arrencar un temporitzador quan el host es connecta, aturar-lo quan es desconnecta, ni recordar l'identificador d'aquest temporitzador entre una crida i la següent. Això exigeix un objecte amb estat propi (l'_idIntervalo, el cercaDeVencer actual) i amb enganxaments al cicle de vida del host —exactament el que la interfície de ReactiveController proporciona de manera estandarditzada, en lloc que cada component reinventi la seva pròpia manera de coordinar temporitzadors amb connectedCallback i disconnectedCallback.

Els controladors reactius són, en la documentació i en la pràctica habitual de l'ecosistema de Lit, l'alternativa recomanada en front d'una altra tècnica més antiga i més general de JavaScript per compondre comportament reutilitzable entre classes: els mixins. Totes dues eines persegueixen el mateix objectiu general (reutilitzar lògica entre diversos components sense copiar i enganxar codi), però ho fan de formes prou diferents com perquè valgui la pena dedicar-los-hi una comparació completa abans de decidir quina usar en cada cas. Aquesta comparació, junt amb el patró dels mixins en si, és el contingut de la lliçó següent.

• Assignar directament una propietat reactiva del host des del controlador: com s'ha assenyalat a l'apartat 5, un controlador no necessita declarar propietats reactives pròpies en el host; li n'hi ha prou amb mantenir el seu propi estat intern i cridar this.host.requestUpdate() quan aquest estat canviï. Intentar fer this.host.cercaDeVencer = ... obligaria a més que el host declarés aquesta propietat en el seu propi static properties, acoblant la implementació interna del controlador a la declaració de propietats de cada host concret.
• Oblidar host.addController(this) dins del propi constructor del controlador: sense aquest registre, Lit mai crida hostConnected ni hostDisconnected, i el controlador es comporta com un objecte corrent sense cap connexió real al cicle de vida del seu host, malgrat que el seu codi pugui semblar correcte a simple vista.
• Fer que el controlador depengui de propietats molt específiques d'un únic component: com més genèric sigui el contracte que el controlador exigeix del seu host (en aquest exemple, una única propietat fechaLimite, amb paràmetres configurables per a la resta), més fàcil serà reutilitzar-lo en components futurs que ni tan sols existeixen encara; un controlador que assumís, per exemple, l'existència d'un mètode molt concret de <task-card> perdria bona part del seu valor com a peça reutilitzable.
• No netejar recursos a hostDisconnected: exactament el mateix risc assenyalat a la lliçó 06-01 sobre disconnectedCallback s'aplica aquí; un controlador que arrenca un temporitzador o una subscripció a hostConnected i no l'allibera a hostDisconnected provoca la mateixa fuga de memòria, ara potencialment multiplicada per cada host que l'usi.

1. Afegeix a ContadorTiempoRestanteController un segon paràmetre de configuració, onCambio, una funció de callback opcional que el controlador invoqui (a més de cridar requestUpdate()) cada vegada que cercaDeVencer canviï de valor, passant-li el nou valor com a argument. Modifica la instanciació a <task-card> per aprofitar aquest callback i mostrar un console.log quan la targeta entri o surti de l'estat "a prop de vèncer".
2. Explica, basant-te en l'apartat 3, quina diferència hi ha entre implementar hostUpdate() en un controlador i sobreescriure willUpdate() directament en la classe del component, quant al lloc on viu físicament el codi.
3. Un company d'equip, en veure el controlador de l'apartat 5, proposa que en lloc de this.host.requestUpdate() seria més simple fer que el propi host exposés una propietat reactiva cercaDeVencer i que el controlador l'assignés directament. Argumenta, basant-te en l'apartat 7 i en el propi codi de l'apartat 6, per què l'enfocament actual (la dada viu en el controlador, no en el host) fa que <task-card> necessiti canviar menys codi si el controlador se substituís en el futur per una implementació diferent.

2. Implementar hostUpdate() en un controlador manté aquest codi físicament dins de la classe del controlador, separat per complet de la classe del component; sobreescriure willUpdate() directament en el component mescla aquest mateix tipus de lògica (alguna cosa que s'ha d'executar abans de render()) dins del propi cos de la classe TaskCard. Tots dos s'executen en el mateix moment exacte del cicle, però només la versió amb controlador permet reutilitzar aquesta lògica en un segon component sense copiar codi: la versió amb willUpdate() directament en la classe queda lligada a aquesta classe concreta.
3. Amb el disseny actual, <task-card> no sap absolutament res sobre com el controlador calcula cercaDeVencer internament: només coneix que this._contadorTiempo exposa una propietat cercaDeVencer llegible a render(). Si en el futur se substituís ContadorTiempoRestanteController per una implementació diferent (per exemple, una que en lloc d'un setInterval usés alguna API del navegador més eficient per a temporitzadors en segon pla), <task-card> no hauria de canviar ni una línia, sempre que la nova implementació continués exposant la mateixa propietat cercaDeVencer. Si, en canvi, el controlador assignés directament this.host.cercaDeVencer, <task-card> hauria de continuar declarant aquesta propietat en el seu propi static properties únicament per donar cabuda a un detall d'implementació intern del controlador, mesclant la superfície pública de <task-card> amb el mecanisme intern d'una peça que, en teoria, hauria de ser substituïble sense fricció.

Aquesta lliçó ha presentat els controladors reactius com l'alternativa recomanada de Lit per encapsular lògica reutilitzable amb estat propi i necessitats de cicle de vida: un objecte corrent de JavaScript, registrat amb addController, capaç d'enganxar-se a hostConnected, hostDisconnected, hostUpdate i hostUpdated exactament en els mateixos punts que ja es coneixien com a mètodes de la pròpia classe d'un component. El temporitzador de <task-card>, fins ara atrapat dins de la seva pròpia classe, viu ara a ContadorTiempoRestanteController, llest per reutilitzar-se en qualsevol altre component de TaskFlow que necessiti el mateix tipus d'avís per proximitat de data.

Queda per resoldre, però, quan convé un controlador reactiu i quan convé l'alternativa més clàssica de JavaScript per a aquest mateix problema general: els mixins. La lliçó següent explica el patró dels mixins aplicat a Lit, les seves limitacions més freqüents, i el criteri concret per triar entre una tècnica i l'altra segons el tipus de comportament que es vulgui compartir.