Ya sabes fabricar el <li> de una tarea. Lo que todavía no tienes es una forma de trabajar: ahora mismo pintas una vez al arrancar y después vas parcheando cada elemento a mano dentro del manejador de clic. Eso funciona con tres acciones y se vuelve inmanejable con quince, porque cada acción tiene que acordarse de actualizar el <li>, el resumen, el contador de horas, el panel de carga y lo que venga después. La alternativa es un cambio de mentalidad: en lugar de describir qué hay que modificar, se escribe una función que describe cómo debe verse la pantalla dado un estado, y se vuelve a llamar cada vez que el estado cambia. En esta lección construirás ese ciclo, aprenderás a agrupar el tablero por columnas, a escapar datos si usas plantillas de texto, y a resolver el problema que aparece en cuanto redibujas todo: que el foco, el desplazamiento y lo que el usuario estaba escribiendo se pierden por el camino.

1. Del nodo suelto a la lista completa: render(estado)
2. El ciclo estado → render → evento → nuevo estado → render
3. Plantillas con template literals y escaparHtml
4. Tres formas de producir HTML, comparadas
5. <template> para las tarjetas
6. Agrupar el tablero por estado con Object.groupBy
7. Estados vacíos, contadores y resumen
8. El problema de redibujar todo
9. Actualización parcial: claves y reutilización de nodos
10. reconciliar(lista, datos)
11. Ordenar y filtrar en la vista sin tocar el modelo
12. Nómada Tareas: vista/tablero-vista.js
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

Compara las dos formas de pensar:

La función render toma el estado y produce la pantalla. Nada más. No sabe qué ha cambiado ni le importa: dibuja lo que hay ahora.

La ventaja no es escribir menos código: es que la pantalla no puede desincronizarse del estado. En la versión imperativa siempre acaba habiendo un caso en que alguien olvida actualizar una de las cinco cosas y la interfaz muestra una mentira. En la declarativa, eso es imposible por construcción.

Esta es la arquitectura de casi cualquier aplicación de interfaz moderna, y ahora la vas a escribir a mano:

Las reglas del ciclo, que conviene respetar con disciplina:

• Un único sentido. El estado alimenta a la pantalla; la pantalla nunca es la fuente de verdad. Si necesitas saber qué tareas están hechas, preguntas al Tablero, no cuentas elementos con clase tarea--hecha.
• Los manejadores no tocan el DOM. Modifican el estado (a través del modelo) y llaman a render(). Uno solo.
• render es (casi) pura. Dado el mismo estado, produce la misma pantalla. Su único efecto secundario es escribir en el DOM.
• El modelo sigue sin saber que existe una pantalla. Tarea y Tablero no cambian ni una línea en esta lección.

Hay una forma de construir HTML que resulta muy legible: los template literals de 01-05, con la estructura escrita tal cual y los datos interpolados.

Se lee de maravilla. Y tal como está escrito, es una vulnerabilidad. En 06-07 Marta podrá escribir el título de una tarea; si escribe <img src=x onerror="…">, ese código se ejecutará en tu página.

La única forma de usar este enfoque con seguridad es escapar todos los datos interpolados, sin excepción:

Detalles que hacen que esta función sea correcta y no una falsa sensación de seguridad:

• & se escapa el primero en el orden de la expresión regular, porque si se escapara después convertiría los < ya generados en <. Usar replace con una función de reemplazo evita el problema de raíz, porque cada carácter se procesa una sola vez.
• Se escapan también las comillas. Sin ellas, un dato interpolado dentro de un atributo (data-id="${valor}") podría cerrar el atributo e inyectar otros. Es un vector real.
• String(valor) protege de null, undefined y números.

Y una advertencia que no hay que olvidar: escapar sirve para contenido de texto y atributos entrecomillados. No es suficiente si interpolas dentro de un <script>, dentro de un style, o en un atributo href/src (donde un javascript: sigue siendo peligroso). Para esos casos, no interpoles: usa nodos.

Con la función, la plantilla queda así:

Funciona, es seguro… y depende de que nadie olvide nunca un esc(). Un solo despiste reabre el agujero. Esa fragilidad es el argumento decisivo contra este enfoque, y la razón de que las alternativas del apartado siguiente sean preferibles.

Conclusión operativa para Nómada Tareas: <template> para la estructura fija de la tarjeta, crearElemento para lo dinámico, y los template literals solo para marcado constante sin datos. Es el equilibrio entre legibilidad y seguridad, y elimina la clase entera de errores de escapado.

Retomamos la plantilla de 06-05 y le damos su forma definitiva, con las columnas incluidas:

Y la función que la rellena. Fíjate en que ahora actualiza un <li> existente si se lo pasas, y solo clona si no hay ninguno: esa doble capacidad es la que hará posible la reconciliación del apartado 10.

Una sola función sirve para crear y para actualizar. Eso es exactamente lo que necesita un render que se ejecuta muchas veces.

El tablero de Taller Nómada tiene tres columnas: pendiente, en curso y hecha. Agrupar es una línea, con lo que aprendiste en 04-05:

Dos avisos sobre Object.groupBy:

• Solo crea las claves que aparecen. Si ninguna tarea está hecha, porEstado.hecha es undefined, no un array vacío. Usa ?? [] siempre.
• El objeto que devuelve tiene el prototipo null, así que no tiene hasOwnProperty ni toString. Para consultar claves, Object.hasOwn(porEstado, 'hecha') o directamente el ??.

Con eso, dibujar las tres columnas es directo:

Con el backlog canónico, el resultado es:

Y 25 + 20 = 45 h abiertas, con 48 h totales. Los números canónicos, ahora repartidos en columnas.

El CSS mínimo para que se vean como tal:

Un detalle que separa una interfaz acabada de un prototipo: qué se ve cuando no hay nada. Una columna vacía sin mensaje parece un error de carga.

Ya lo has resuelto arriba con $('.columna__vacia', columna).hidden = delEstado.length > 0, pero conviene distinguir tres situaciones distintas, porque el mensaje adecuado no es el mismo:

Y el resumen global, que reutiliza el método del modelo:

Ese elemento lleva role="status" en el HTML (06-01), de modo que un lector de pantalla anuncia el nuevo resumen cada vez que cambia, sin robar el foco.

Y ahora la mala noticia. replaceChildren(...) destruye todos los nodos y crea otros. Eso tiene cuatro consecuencias visibles:

1. Se pierde el foco. Si Marta había llegado con el tabulador al botón «Marcar hecha» de la tercera tarea y pulsa Enter, el render la deja con el foco en document.body. Su siguiente Tab la lleva al principio de la página.
2. Se pierde el desplazamiento dentro de contenedores con barra propia.
3. Se pierde el estado del navegador: texto seleccionado, <details> abiertos, la posición del cursor dentro de un <input> que estuviera en la lista.
4. Se reinician las transiciones CSS, porque los elementos son nuevos.

Hay dos estrategias para resolverlo.

Estrategia A: salvar y restaurar. Antes de redibujar, anota qué estaba enfocado; después, vuelve a buscarlo por su clave estable y devuélvele el foco.

Funciona y es sencilla, pero es un parche: cuantas más cosas haya que conservar, más frágil se vuelve.

Estrategia B: no destruir lo que no ha cambiado. Es la buena, y es lo que hacen los frameworks. En lugar de vaciar y recrear, se compara la lista de nodos actuales con los datos nuevos y se reutiliza cada nodo que siga siendo válido, actualizando solo su contenido.

Para reutilizar un nodo hay que poder identificarlo. La posición no vale: si la primera tarea desaparece, todas las demás se desplazan y el nodo de la segunda pasaría a representar a la tercera, con el foco y las animaciones en el sitio equivocado.

Lo que vale es una clave estable: un identificador que pertenezca al dato, no a su posición. En Nómada Tareas ya la tienes desde 06-02: data-id.

Aquí está la implementación, y es más corta de lo que parece:

Explicación línea a línea de lo que hace y por qué:

• Paso 1: construye un Map de clave → nodo con lo que hay en pantalla. Es exactamente el patrón de indexar por id de 04-05, aplicado a nodos en lugar de a objetos.
• Paso 2: recorre los datos en el orden en que deben quedar. Para cada uno, si ya existía un nodo con esa clave lo reutiliza (pintar(dato, previo) lo actualiza en lugar de clonar), y si no, crea uno nuevo. Después lo coloca en su posición con insertBefore, que —recuerda 06-05— mueve el nodo si ya estaba en el árbol.
• Paso 3: lo que queda en el Map son nodos cuya clave ya no aparece en los datos. Se eliminan.

El resultado: los nodos de las tareas que siguen ahí nunca se destruyen. Conservan su foco, sus transiciones y cualquier estado del navegador.

Compruébalo: pon el foco en el botón «Empezar» de la tercera tarea, pulsa Enter y observa que el foco sigue ahí después del render, con el botón ya cambiado a «Marcar hecha». Con replaceChildren habría desaparecido.

Los límites de esta implementación. Es deliberadamente sencilla y no es un algoritmo de reconciliación completo: no detecta movimientos de forma óptima (puede mover más nodos de los estrictamente necesarios) y solo funciona con hijos directos que tengan clave. Para una lista de tareas es más que suficiente. Para una interfaz grande, con árboles anidados y componentes, hacer esto a mano se vuelve inviable, y ahí es donde entran los frameworks: React, Vue y Angular resuelven este problema exacto —y por eso todos ellos te piden una key en las listas, que es literalmente este data-id—. Lo verás en Por Qué Existen los Frameworks, y llegarás a esa lección sabiendo qué problema resuelven, que es la única forma de entenderlos de verdad.

Filtrar y ordenar son decisiones de presentación. El Tablero no debe enterarse: si Lucía filtra por su nombre, el tablero sigue teniendo seis tareas y 45 h abiertas; lo único que cambia es lo que se muestra.

Tres puntos importantes:

• tablero.tareas ya devuelve una copia ([...this.#tareas], encapsulación de 05-03), así que el .sort(), que muta, no toca el array interno del modelo. Si el getter devolviera el array real, este sort reordenaría el modelo: un fallo sutil y desagradable.
• La comparadora prioridad usa || como desempate: si dos tareas tienen la misma prioridad, se ordenan por id. Sin desempate, el orden entre iguales dependería del algoritmo y podría cambiar entre renders, produciendo saltos visuales.
• localeCompare(texto, 'es') ordena correctamente los acentos y la ñ, cosa que el < de las cadenas no hace.

El módulo completo, que junta todo lo anterior:

Y el punto de entrada, que ya es puro cableado:

Todo el ciclo del apartado 2, en veinte líneas: el manejador delegado toca el modelo y llama a render(); render() dibuja lo que hay. Al marcar la carpintería como hecha, la tarjeta se mueve de la columna «Pendientes» a «Hechas» sin destruirse, los contadores pasan de 3 tareas · 25 h a 2 tareas · 20 h y de 1 tarea · 3 h a 2 tareas · 8 h, el resumen baja de 45 a 40 h abiertas y de 1 vencida a 0, y el foco sigue exactamente donde estaba.

• Interpolar datos sin escapar en una plantilla de texto. Basta un ${} olvidado para abrir un XSS. Si eliges este enfoque, escapa siempre; si puedes, usa <template> o nodos y elimina la clase entera de errores.
• Usar el índice del array como clave. data-id="${indice}" parece funcionar hasta que se elimina un elemento del medio: entonces todos los nodos representan al dato equivocado. La clave debe pertenecer al dato.
• Olvidar ?? [] con Object.groupBy. Solo crea las claves que aparecen; una columna sin tareas da undefined y el .map siguiente lanza TypeError.
• Ordenar el array del modelo. sort muta. Funciona aquí porque tablero.tareas devuelve una copia; si algún getter devolviera el array interno, estarías reordenando el modelo desde la vista. Ante la duda, [...lista].sort(...).
• Redibujar dentro de un bucle de eventos rápido. Un render() completo por cada pulsación de tecla en un campo de búsqueda es trabajo desperdiciado. La solución es el debounce que verás en 06-07.
• Poner manejadores dentro de render. Si render registra manejadores, cada llamada añade otro y acabas con la acción ejecutándose cinco veces. Los manejadores se registran una vez, por delegación, fuera del render.
• Redibujar y perder el foco sin darse cuenta. Es un fallo de accesibilidad serio y silencioso: quien usa ratón no lo nota nunca. Pruébalo siempre con el tabulador.
• Consejo: mantén render() sin efectos ocultos. Que solo lea el estado y escriba en el DOM. Si hace peticiones, cambia el modelo o dispara acciones, deja de ser predecible y depurar se vuelve muy difícil.
• Consejo: guarda el estado de la vista en un solo objeto. Tener filtros, orden y hoy en un único #estado hace trivial responder a «¿por qué se ve esto?»: imprimes el objeto y lo sabes.

Añade al HTML un <input type="search" id="buscar"> con su <label> y conéctalo para que al escribir se filtren las tareas por título. Debe usar estado.filtros.texto, no tocar el modelo, y mostrar en el resumen cuántas se están viendo. Comprueba con el tabulador que el foco no se sale del campo de búsqueda al escribir, y explica por qué la reconciliación es imprescindible aquí.

Añade un <select id="orden"> con las opciones prioridad, fecha límite y horas, y haz que al cambiarlo se reordenen las tarjetas. Después comprueba, con las DevTools, que al reordenar los nodos se mueven en lugar de recrearse: pon un data-marca en un <li> desde la consola, reordena, y verifica que la marca sigue ahí.

Añade un botón data-accion="eliminar" a la tarjeta y un método eliminar(id) al Tablero. Comprueba que tras eliminar una tarea del medio, las tarjetas restantes conservan sus nodos (no se recrean) y que el foco pasa al botón equivalente de la tarea siguiente. Explica qué habría ocurrido si reconciliar usara la posición en lugar de data-id.

Ejercicio 1

La reconciliación es imprescindible aquí por un motivo muy concreto: el evento input se dispara en cada pulsación, así que cada letra provoca un render(). Si ese render hiciera replaceChildren, destruiría y recrearía todas las tarjetas veinte veces mientras Marta escribe «serigrafía». No perdería el foco del <input> —está fuera del contenedor reconciliado—, pero sí desperdiciaría muchísimo trabajo, reiniciaría las transiciones CSS en cada tecla y produciría un parpadeo perfectamente visible. Con reconciliar, cada pulsación solo elimina las tarjetas que dejan de coincidir y devuelve las que vuelven a coincidir.

Escribiendo «carpint», el resumen muestra 6 tareas · 5 abiertas · 45 de 48 h · 1 vencida · esfuerzo 124 · mostrando 1: los números del modelo no cambian, solo la cuenta de lo mostrado. Es exactamente la separación que buscábamos.

Ejercicio 2

Comprobación de que los nodos se mueven y no se recrean:

Si la marca sobrevive, es que reconciliar reutilizó el nodo y solo lo recolocó con insertBefore. Con replaceChildren la marca habría desaparecido, porque el <li> sería otro objeto distinto. Este truco del atributo testigo es, por cierto, una técnica de depuración excelente para verificar cualquier estrategia de reutilización de nodos.

Nota: change es el evento adecuado para un <select>; input también funciona, pero change expresa mejor la intención de «ha elegido una opción».

Ejercicio 3

Si reconciliar identificara los nodos por posición, al eliminar la tarea del medio ocurriría lo siguiente: el nodo que ocupaba la posición 2 se rellenaría con los datos de la tarea que antes estaba en la 3, el de la 3 con los de la 4, y así hasta el final; el último nodo se eliminaría. Visualmente el resultado sería correcto, pero todos los nodos habrían cambiado de dato: el foco, que estaba en la tarjeta de la posición 3, acabaría en una tarjeta que ahora muestra otra tarea; cualquier transición CSS en curso se aplicaría al elemento equivocado; y cualquier estado del navegador ligado a un nodo (un <details> desplegado, por ejemplo) se atribuiría a la tarea que no era.

Con data-id como clave, el nodo de cada tarea sigue siendo suyo pase lo que pase: solo se elimina el nodo cuya clave desaparece de los datos. Es exactamente por esto que React, Vue y Angular insisten tanto en la prop key de las listas, y verlo desde dentro te va a ahorrar mucho tiempo cuando llegues al Módulo 10.

Has pasado de manipular nodos sueltos a tener una arquitectura. El eje es la función render(estado), que describe cómo debe verse la pantalla dado un estado, y el ciclo estado → render → evento → nuevo estado → render, con sus reglas: un solo sentido, los manejadores no tocan el DOM (cambian el estado y llaman a render), y el modelo sigue sin saber que existe una pantalla. La ventaja no es escribir menos, sino que la interfaz no puede desincronizarse de los datos, que es la clase de error más difícil de perseguir en una aplicación imperativa.

Conoces las tres maneras de producir HTML y el criterio para elegir. Los template literals son los más legibles y los más peligrosos: exigen escapar cada dato con una función escaparHtml que traduzca & < > " ', y basta un olvido para abrir un XSS. La construcción con nodos es segura por definición. Y <template> con content.cloneNode(true) combina la legibilidad de tener la estructura en el HTML con la seguridad de rellenar mediante textContent, que es la opción adoptada en el proyecto. Sobre ella has escrito pintarTarjeta(tarea, existente), una función que crea o actualiza según le pases o no un nodo previo: la propiedad que hace posible todo lo demás.

Sabes agrupar el tablero por columnas con Object.groupBy, con el recordatorio de que solo crea las claves presentes y de que hace falta ?? []; dibujar contadores por columna (3 tareas y 25 h pendientes, 2 y 20 h en curso, 1 y 3 h hechas, que suman las 45 h abiertas de siempre); y cuidar los estados vacíos con mensajes distintos según sea una columna vacía, un filtro sin resultados o un tablero recién estrenado. Y, sobre todo, sabes qué pasa cuando se redibuja todo con replaceChildren: se pierden el foco, el desplazamiento, la selección y el estado del navegador, un fallo de accesibilidad que quien usa ratón no percibe nunca. La respuesta está en las claves estables: reconciliar(contenedor, datos, clave, pintar) indexa los nodos existentes en un Map por su data-id, reutiliza los que siguen vivos actualizando su contenido, los recoloca con insertBefore y elimina los sobrantes. Los nodos supervivientes conservan su identidad, y con ella el foco y las transiciones. Filtrar y ordenar, por último, son decisiones de la vista: viven en su estado, operan sobre la copia que devuelve tablero.tareas y jamás alteran el modelo.

Ese reconciliar de veinte líneas es también una lección sobre el oficio: hacerlo bien para una lista plana con clave es asequible; hacerlo para árboles anidados de componentes, con orden arbitrario y actualizaciones parciales, es el trabajo que hacen React, Vue y Angular. Llegarás al Módulo 10 sabiendo exactamente qué problema resuelven y por qué todos te piden una key.

Queda una última pieza, y es la que convierte el tablero en una herramienta de verdad. Marta puede mover tareas y filtrarlas, pero no puede crear ninguna: el backlog sigue siendo el de datos/backlog.js. Dar de alta una tarea significa un formulario, y un formulario trae consigo un mundo propio: campos accesibles con sus etiquetas, valores que llegan siempre como texto, validación nativa del navegador frente a validación en JavaScript, reglas de negocio que deben seguir viviendo en el modelo, mensajes de error que un lector de pantalla pueda anunciar, y el foco puesto donde corresponde cuando algo falla. Todo eso es Manejo y Validación de Formularios, la última lección del módulo.