Las dos lecciones anteriores han dejado a <task-card> con una pieza de lógica autocontenida pero atrapada dentro de su propia clase: un temporizador que arranca en connectedCallback, se detiene en disconnectedCallback, y un cálculo (_calcularSiCercaDeVencer) que ambos comparten. Funciona perfectamente para <task-card>, pero si mañana <task-board> necesitara mostrar, por ejemplo, un resumen con el número de tareas cercanas a su fecha límite, esa misma lógica tendría que copiarse y pegarse en una segunda clase, con el riesgo de que las dos copias acaben divergiendo con el tiempo. Esta lección presenta la herramienta que Lit ofrece específicamente para este problema: los controladores reactivos, objetos reutilizables capaces de engancharse al ciclo de vida de cualquier componente sin necesidad de heredar de él.

1. El problema: lógica con ciclo de vida propio, atrapada en una clase
2. Qué es un ReactiveController
3. La interfaz de un controlador: hostConnected, hostDisconnected, hostUpdate, hostUpdated
4. addController: registrando un controlador en su host
5. Extrayendo el temporizador de <task-card> a un controlador reutilizable
6. Usando el controlador desde <task-card>
7. Por qué un controlador y no simplemente una función auxiliar
8. Cierre: controladores frente a mixins

La lógica añadida en la lección 06-01 tiene una característica particular que la distingue de un simple método auxiliar: necesita engancharse al ciclo de vida del componente que la usa. No basta con extraer _calcularSiCercaDeVencer a una función independiente (eso ya sería trivial, sin necesidad de ningún concepto nuevo); el problema de fondo es que el temporizador en sí —cuándo arranca, cuándo se detiene— depende de cuándo <task-card> se conecta y se desconecta del DOM, y esa dependencia del ciclo de vida es, precisamente, lo que hace que copiar y pegar esta lógica en un segundo componente sea tan tentador como propenso a errores: cualquier corrección futura (por ejemplo, ajustar el margen de "cerca de vencer" de 24 horas a 48) tendría que aplicarse en todas las copias por separado.

Un ReactiveController es, en su forma más simple, un objeto corriente de JavaScript (no necesita heredar de ninguna clase de Lit) que implementa una o varias de un pequeño conjunto de funciones con nombres reservados, y que se registra explícitamente sobre un componente Lit (llamado, en esta relación, su host) para recibir avisos en los mismos momentos clave del ciclo de vida que ya se han estudiado en las lecciones anteriores de este módulo.

La idea central, y la que resuelve el problema del apartado 1, es que un mismo controlador —una misma clase de JavaScript— puede registrarse sobre tantos hosts distintos como haga falta, cada uno con su propia instancia del controlador, sin que ninguno necesite heredar de una clase base común ni duplicar código: el controlador encapsula tanto el estado (por ejemplo, el identificador del intervalo activo) como el comportamiento (arrancarlo, detenerlo, calcular el resultado), y el componente que lo usa se limita a mantener una referencia al controlador y a leer, desde su render(), el dato que el controlador expone.

Un controlador puede implementar cualquiera de estos métodos, todos opcionales, y Lit los llama automáticamente en el momento correspondiente del ciclo de vida de su host:

Esta correspondencia no es casual: los controladores reactivos están diseñados deliberadamente como una vía alternativa para engancharse a los mismos puntos exactos del ciclo de vida que ya se han estudiado como métodos de la propia clase del componente, con la diferencia de que, en lugar de vivir mezclados dentro de la clase del componente, viven en un objeto aparte, reutilizable de forma independiente.

Para que un controlador empiece a recibir estos avisos, su host —cualquier LitElement, sin necesidad de ninguna configuración adicional— debe registrarlo explícitamente con this.addController(controlador), normalmente dentro del constructor del componente:

Es habitual, como en este ejemplo, que el propio constructor del controlador reciba el host como argumento y llame él mismo a host.addController(this) internamente, de forma que instanciar el controlador y registrarlo sea un único paso, tal como se verá en el apartado siguiente. A partir de ese registro, Lit se encarga de invocar los métodos de la tabla anterior en el momento adecuado, exactamente igual que si fueran métodos de la propia clase del componente.

Con la interfaz ya clara, la lógica de la lección 06-01 se traslada, casi sin cambios conceptuales, a una clase independiente:

Varios detalles distinguen este código del original de la lección 06-01, y todos responden a la misma necesidad: hacerlo reutilizable por cualquier host, no solo por <task-card>.

• El constructor guarda una referencia al host recibido como parámetro, y llama él mismo a host.addController(this): quien use este controlador no necesita acordarse de llamar a addController por separado, basta con instanciarlo pasándole this (el propio componente) como argumento.
• El margen de "cerca de vencer" (margenMs) y la frecuencia de comprobación (intervaloMs) se han convertido en parámetros configurables, con valores por defecto razonables, en lugar de estar fijados directamente en el código como en la lección 06-01: esto permite que un futuro segundo host use, por ejemplo, un margen de 48 horas sin tener que copiar y modificar el controlador.
• El controlador lee this.host.fechaLimite directamente, asumiendo que cualquier host que lo use expondrá una propiedad con ese nombre. Esta es la única suposición que el controlador hace sobre su host, y conviene documentarla con claridad: un controlador reutilizable siempre necesita algún contrato mínimo sobre lo que su host debe ofrecerle.
• Fundamental: en lugar de asignar directamente una propiedad reactiva del host (this.host.cercaDeVencer = ..., como hacía <task-card> en la lección 06-01), el controlador guarda su propio resultado en un campo propio (this.cercaDeVencer, en el propio controlador, no en el host) y llama explícitamente a this.host.requestUpdate() para pedirle a Lit que vuelva a ejecutar render(). El controlador no necesita declarar ninguna propiedad reactiva de Lit para su propio estado interno; le basta con requestUpdate(), exactamente el mismo mecanismo de bajo nivel estudiado en el módulo 2, para provocar una actualización cada vez que su resultado cambia.

Con el controlador ya extraído, <task-card> se simplifica notablemente: desaparecen connectedCallback, disconnectedCallback y _calcularSiCercaDeVencer de la lección 06-01, sustituidos por una única instancia del controlador.

Nótese que cercaDeVencer ya no existe como propiedad de estado de <task-card> (ha desaparecido de static properties): ahora vive exclusivamente dentro del controlador, y render() lo lee directamente como this._contadorTiempo.cercaDeVencer. <task-card> ni siquiera necesita saber que, internamente, ese valor se actualiza mediante un setInterval; solo necesita saber que el controlador expone una propiedad cercaDeVencer legible en cualquier momento, y que Lit volverá a ejecutar render() automáticamente cada vez que ese valor cambie, gracias al requestUpdate() que el propio controlador invoca.

Si más adelante <task-board> necesitara mostrar cuántas tareas están cerca de vencer, podría instanciar su propio ContadorTiempoRestanteController para cada tarea de this.tareas (o, más simple, reutilizar el mismo cálculo agregándolo desde varias instancias ya creadas en cada <task-card>), sin duplicar ni una sola línea de la lógica del temporizador: el controlador ya está escrito, probado y listo para usarse en cualquier host que exponga una propiedad fechaLimite.

Cabe preguntarse por qué hace falta un objeto con esta interfaz concreta, en lugar de limitarse a extraer _calcularSiCercaDeVencer a una función suelta e importarla donde haga falta. La respuesta está en lo que una función suelta no puede resolver por sí sola: el ciclo de vida y el estado que persiste entre llamadas. Una función auxiliar sin estado propio serviría perfectamente para el cálculo puntual (_calcularSiCercaDeVencer(fechaLimite) ya lo era, de hecho, desde la lección 06-01), pero no puede, por sí misma, arrancar un temporizador cuando el host se conecta, detenerlo cuando se desconecta, ni recordar el identificador de ese temporizador entre una llamada y la siguiente. Eso exige un objeto con estado propio (el _idIntervalo, el cercaDeVencer actual) y con enganches al ciclo de vida del host —exactamente lo que la interfaz de ReactiveController proporciona de forma estandarizada, en lugar de que cada componente reinvente su propia manera de coordinar temporizadores con connectedCallback y disconnectedCallback.

Los controladores reactivos son, en la documentación y en la práctica habitual del ecosistema de Lit, la alternativa recomendada frente a otra técnica más antigua y más general de JavaScript para componer comportamiento reutilizable entre clases: los mixins. Ambas herramientas persiguen el mismo objetivo general (reutilizar lógica entre varios componentes sin copiar y pegar código), pero lo hacen de formas suficientemente distintas como para que merezca la pena dedicarles una comparación completa antes de decidir cuál usar en cada caso. Esa comparación, junto con el patrón de los mixins en sí, es el contenido de la siguiente lección.

• Asignar directamente una propiedad reactiva del host desde el controlador: como se ha señalado en el apartado 5, un controlador no necesita declarar propiedades reactivas propias en el host; le basta con mantener su propio estado interno y llamar a this.host.requestUpdate() cuando ese estado cambie. Intentar hacer this.host.cercaDeVencer = ... obligaría además a que el host declarase esa propiedad en su propio static properties, acoplando la implementación interna del controlador a la declaración de propiedades de cada host concreto.
• Olvidar host.addController(this) dentro del propio constructor del controlador: sin este registro, Lit nunca llama a hostConnected ni a hostDisconnected, y el controlador se comporta como un objeto corriente sin ninguna conexión real al ciclo de vida de su host, a pesar de que su código pueda parecer correcto a simple vista.
• Hacer que el controlador dependa de propiedades muy específicas de un único componente: cuanto más genérico sea el contrato que el controlador exige de su host (en este ejemplo, una única propiedad fechaLimite, con parámetros configurables para el resto), más fácil será reutilizarlo en componentes futuros que ni siquiera existen todavía; un controlador que asumiera, por ejemplo, la existencia de un método muy concreto de <task-card> perdería buena parte de su valor como pieza reutilizable.
• No limpiar recursos en hostDisconnected: exactamente el mismo riesgo señalado en la lección 06-01 sobre disconnectedCallback se aplica aquí; un controlador que arranca un temporizador o una suscripción en hostConnected y no lo libera en hostDisconnected provoca la misma fuga de memoria, ahora potencialmente multiplicada por cada host que lo use.

1. Añade al ContadorTiempoRestanteController un segundo parámetro de configuración, onCambio, una función de callback opcional que el controlador invoque (además de llamar a requestUpdate()) cada vez que cercaDeVencer cambie de valor, pasándole el nuevo valor como argumento. Modifica la instanciación en <task-card> para aprovechar este callback y mostrar un console.log cuando la tarjeta entre o salga del estado "cerca de vencer".
2. Explica, basándote en el apartado 3, qué diferencia hay entre implementar hostUpdate() en un controlador y sobreescribir willUpdate() directamente en la clase del componente, en cuanto al lugar donde vive físicamente el código.
3. Un compañero de equipo, al ver el controlador del apartado 5, propone que en lugar de this.host.requestUpdate() sería más simple hacer que el propio host expusiera una propiedad reactiva cercaDeVencer y que el controlador la asignara directamente. Argumenta, basándote en el apartado 7 y en el propio código del apartado 6, por qué el enfoque actual (el dato vive en el controlador, no en el host) hace que <task-card> necesite cambiar menos código si el controlador se sustituyera en el futuro por una implementación distinta.

2. Implementar hostUpdate() en un controlador mantiene ese código físicamente dentro de la clase del controlador, separado por completo de la clase del componente; sobreescribir willUpdate() directamente en el componente mezcla ese mismo tipo de lógica (algo que debe ejecutarse antes de render()) dentro del propio cuerpo de la clase TaskCard. Ambos se ejecutan en el mismo momento exacto del ciclo, pero solo la versión con controlador permite reutilizar esa lógica en un segundo componente sin copiar código: la versión con willUpdate() directamente en la clase queda atada a esa clase concreta.
3. Con el diseño actual, <task-card> no sabe absolutamente nada sobre cómo el controlador calcula cercaDeVencer internamente: solo conoce que this._contadorTiempo expone una propiedad cercaDeVencer legible en render(). Si en el futuro se sustituyera ContadorTiempoRestanteController por una implementación distinta (por ejemplo, una que en lugar de un setInterval usara alguna API del navegador más eficiente para temporizadores en segundo plano), <task-card> no tendría que cambiar ni una línea, siempre que la nueva implementación siguiera exponiendo la misma propiedad cercaDeVencer. Si, en cambio, el controlador asignara directamente this.host.cercaDeVencer, <task-card> tendría que seguir declarando esa propiedad en su propio static properties únicamente para dar cabida a un detalle de implementación interno del controlador, mezclando la superficie pública de <task-card> con el mecanismo interno de una pieza que, en teoría, debería ser sustituible sin fricciones.

Esta lección ha presentado los controladores reactivos como la alternativa recomendada de Lit para encapsular lógica reutilizable con estado propio y necesidades de ciclo de vida: un objeto corriente de JavaScript, registrado con addController, capaz de engancharse a hostConnected, hostDisconnected, hostUpdate y hostUpdated exactamente en los mismos puntos que ya se conocían como métodos de la propia clase de un componente. El temporizador de <task-card>, hasta ahora atrapado dentro de su propia clase, vive ahora en ContadorTiempoRestanteController, listo para reutilizarse en cualquier otro componente de TaskFlow que necesite el mismo tipo de aviso por proximidad de fecha.

Queda por resolver, sin embargo, cuándo conviene un controlador reactivo y cuándo conviene la alternativa más clásica de JavaScript para este mismo problema general: los mixins. La siguiente lección explica el patrón de los mixins aplicado a Lit, sus limitaciones más frecuentes, y el criterio concreto para elegir entre una técnica y otra según el tipo de comportamiento que se quiera compartir.