Ja saps fabricar el <li> d'una tasca. El que encara no tens és una manera de treballar: ara mateix pintes una vegada en arrencar i després vas apedaçant cada element a mà dins del gestor de clic. Això funciona amb tres accions i es torna inmanejable amb quinze, perquè cada acció s'ha de recordar d'actualitzar el <li>, el resum, el comptador d'hores, el panell de càrrega i el que vingui després. L'alternativa és un canvi de mentalitat: en lloc de descriure què cal modificar, s'escriu una funció que descriu com ha de veure's la pantalla donat un estat, i es torna a cridar cada vegada que l'estat canvia. En aquesta lliçó construiràs aquell cicle, aprendràs a agrupar el tauler per columnes, a escapar dades si fas servir plantilles de text, i a resoldre el problema que apareix tan bon punt redibuixes tot: que el focus, el desplaçament i el que l'usuari estava escrivint es perden pel camí.

1. Del node solt a la llista completa: render(estat)
2. El cicle estat → render → esdeveniment → estat nou → render
3. Plantilles amb template literals i escaparHtml
4. Tres maneres de produir HTML, comparades
5. <template> per a les targetes
6. Agrupar el tauler per estat amb Object.groupBy
7. Estats buits, comptadors i resum
8. El problema de redibuixar-ho tot
9. Actualització parcial: claus i reutilització de nodes
10. reconciliar(llista, dades)
11. Ordenar i filtrar a la vista sense tocar el model
12. Nómada Tasques: vista/tauler-vista.js
13. Errors Habituals i Consells
14. Exercicis
15. Conclusió

Compara les dues maneres de pensar:

La funció render pren l'estat i produeix la pantalla. Res més. No sap què ha canviat ni li importa: dibuixa el que hi ha ara.

L'avantatge no és escriure menys codi: és que la pantalla no es pot desincronitzar de l'estat. A la versió imperativa sempre acaba havent-hi un cas en què algú s'oblida d'actualitzar una de les cinc coses i la interfície mostra una mentida. A la declarativa, això és impossible per construcció.

Aquesta és l'arquitectura de gairebé qualsevol aplicació d'interfície moderna, i ara l'escriuràs a mà:

Les regles del cicle, que convé respectar amb disciplina:

• Un únic sentit. L'estat alimenta la pantalla; la pantalla no és mai la font de veritat. Si necessites saber quines tasques estan fetes, ho preguntes al Tauler, no comptes elements amb classe tasca--feta.
• Els gestors no toquen el DOM. Modifiquen l'estat (a través del model) i criden render(). Un de sol.
• render és (gairebé) pura. Donat el mateix estat, produeix la mateixa pantalla. El seu únic efecte secundari és escriure al DOM.
• El model continua sense saber que existeix una pantalla. Tasca i Tauler no canvien ni una línia en aquesta lliçó.

Hi ha una manera de construir HTML que resulta molt llegible: els template literals de 01-05, amb l'estructura escrita tal qual i les dades interpolades.

Es llegeix de meravella. I tal com està escrit, és una vulnerabilitat. A 06-07 la Marta podrà escriure el títol d'una tasca; si escriu <img src=x onerror="…">, aquell codi s'executarà a la teva pàgina.

L'única manera de fer servir aquest enfocament amb seguretat és escapar totes les dades interpolades, sense excepció:

Detalls que fan que aquesta funció sigui correcta i no una falsa sensació de seguretat:

• & s'escapa el primer en l'ordre de l'expressió regular, perquè si s'escapés després convertiria els < ja generats en <. Fer servir replace amb una funció de reemplaçament evita el problema d'arrel, perquè cada caràcter es processa una sola vegada.
• També s'escapen les cometes. Sense elles, una dada interpolada dins d'un atribut (data-id="${valor}") podria tancar l'atribut i injectar-ne d'altres. És un vector real.
• String(valor) protegeix de null, undefined i números.

I una advertència que no s'ha d'oblidar: escapar serveix per a contingut de text i atributs entre cometes. No n'hi ha prou si interpoles dins d'un <script>, dins d'un style, o en un atribut href/src (on un javascript: continua sent perillós). Per a aquells casos, no interpolis: fes servir nodes.

Amb la funció, la plantilla queda així:

Funciona, és segur… i depèn que ningú no s'oblidi mai d'un esc(). Una sola distracció reobre el forat. Aquella fragilitat és l'argument decisiu contra aquest enfocament, i la raó que les alternatives de l'apartat següent siguin preferibles.

Conclusió operativa per a Nómada Tasques: <template> per a l'estructura fixa de la targeta, crearElement per al que és dinàmic, i els template literals només per a marcatge constant sense dades. És l'equilibri entre llegibilitat i seguretat, i elimina la classe sencera d'errors d'escapament.

Reprenem la plantilla de 06-05 i li donem la seva forma definitiva, amb les columnes incloses:

I la funció que la omple. Fixa't que ara actualitza un <li> existent si li'n passes un, i només clona si no n'hi ha cap: aquella doble capacitat és la que farà possible la reconciliació de l'apartat 10.

Una sola funció serveix per crear i per actualitzar. Això és exactament el que necessita un render que s'executa moltes vegades.

El tauler de Taller Nómada té tres columnes: pendent, en curs i feta. Agrupar és una línia, amb el que vas aprendre a 04-05:

Dos avisos sobre Object.groupBy:

• Només crea les claus que apareixen. Si cap tasca no està feta, perEstat.feta és undefined, no un array buit. Fes servir ?? [] sempre.
• L'objecte que retorna té el prototip null, així que no té hasOwnProperty ni toString. Per consultar claus, Object.hasOwn(perEstat, 'feta') o directament el ??.

Amb això, dibuixar les tres columnes és directe:

Amb el backlog canònic, el resultat és:

I 25 + 20 = 45 h obertes, amb 48 h totals. Els números canònics, ara repartits en columnes.

El CSS mínim perquè es vegin com a tals:

Un detall que separa una interfície acabada d'un prototip: què es veu quan no hi ha res. Una columna buida sense missatge sembla un error de càrrega.

Ja ho has resolt més amunt amb $('.columna__buida', columna).hidden = delEstat.length > 0, però convé distingir tres situacions diferents, perquè el missatge adequat no és el mateix:

I el resum global, que reutilitza el mètode del model:

Aquell element porta role="status" a l'HTML (06-01), de manera que un lector de pantalla anuncia el resum nou cada vegada que canvia, sense robar el focus.

I ara la mala notícia. replaceChildren(...) destrueix tots els nodes i en crea d'altres. Això té quatre conseqüències visibles:

1. Es perd el focus. Si la Marta havia arribat amb el tabulador al botó «Marcar feta» de la tercera tasca i prem Enter, el render la deixa amb el focus a document.body. El seu Tab següent la porta al principi de la pàgina.
2. Es perd el desplaçament dins de contenidors amb barra pròpia.
3. Es perd l'estat del navegador: text seleccionat, <details> oberts, la posició del cursor dins d'un <input> que hi hagués a la llista.
4. Es reinicien les transicions CSS, perquè els elements són nous.

Hi ha dues estratègies per resoldre-ho.

Estratègia A: salvar i restaurar. Abans de redibuixar, apunta què estava enfocat; després, torna a buscar-ho per la seva clau estable i torna-li el focus.

Funciona i és senzilla, però és un apedaçament: com més coses hi hagi a conservar, més fràgil es torna.

Estratègia B: no destruir el que no ha canviat. És la bona, i és el que fan els frameworks. En lloc de buidar i recrear, es compara la llista de nodes actuals amb les dades noves i es reutilitza cada node que continuï sent vàlid, actualitzant només el seu contingut.

Per reutilitzar un node cal poder identificar-lo. La posició no val: si la primera tasca desapareix, totes les altres es desplacen i el node de la segona passaria a representar la tercera, amb el focus i les animacions al lloc equivocat.

El que val és una clau estable: un identificador que pertanyi a la dada, no a la seva posició. A Nómada Tasques ja la tens des de 06-02: data-id.

Aquí està la implementació, i és més curta del que sembla:

Explicació línia a línia del que fa i per què:

• Pas 1: construeix un Map de clau → node amb el que hi ha a la pantalla. És exactament el patró d'indexar per id de 04-05, aplicat a nodes en lloc d'objectes.
• Pas 2: recorre les dades en l'ordre en què han de quedar. Per a cadascuna, si ja existia un node amb aquella clau el reutilitza (pintar(dada, previ) l'actualitza en lloc de clonar), i si no, en crea un de nou. Després el col·loca a la seva posició amb insertBefore, que —recorda 06-05— mou el node si ja era a l'arbre.
• Pas 3: el que queda al Map són nodes la clau dels quals ja no apareix a les dades. S'eliminen.

El resultat: els nodes de les tasques que continuen allà no es destrueixen mai. Conserven el seu focus, les seves transicions i qualsevol estat del navegador.

Comprova-ho: posa el focus al botó «Començar» de la tercera tasca, prem Enter i observa que el focus continua allà després del render, amb el botó ja canviat a «Marcar feta». Amb replaceChildren hauria desaparegut.

Els límits d'aquesta implementació. És deliberadament senzilla i no és un algorisme de reconciliació complet: no detecta moviments de manera òptima (pot moure més nodes dels estrictament necessaris) i només funciona amb fills directes que tinguin clau. Per a una llista de tasques és més que suficient. Per a una interfície gran, amb arbres imbricats i components, fer això a mà es torna inviable, i aquí és on entren els frameworks: React, Vue i Angular resolen aquest problema exacte —i per això tots ells et demanen una key a les llistes, que és literalment aquest data-id—. Ho veuràs a Per Què Existeixen els Frameworks, i arribaràs a aquella lliçó sabent quin problema resolen, que és l'única manera d'entendre'ls de debò.

Filtrar i ordenar són decisions de presentació. El Tauler no se n'ha d'assabentar: si la Lucía filtra pel seu nom, el tauler continua tenint sis tasques i 45 h obertes; l'única cosa que canvia és el que es mostra.

Tres punts importants:

• tauler.tasques ja retorna una còpia ([...this.#tasques], encapsulació de 05-03), així que el .sort(), que muta, no toca l'array intern del model. Si el getter retornés l'array real, aquest sort reordenaria el model: una fallada subtil i desagradable.
• La comparadora prioritat fa servir || com a desempat: si dues tasques tenen la mateixa prioritat, s'ordenen per id. Sense desempat, l'ordre entre iguals dependria de l'algorisme i podria canviar entre renders, produint salts visuals.
• localeCompare(text, 'ca') ordena correctament els accents i la ç, cosa que el < de les cadenes no fa.

El mòdul complet, que ajunta tot l'anterior:

I el punt d'entrada, que ja és pur cablejat:

Tot el cicle de l'apartat 2, en vint línies: el gestor delegat toca el model i crida render(); render() dibuixa el que hi ha. En marcar la fusteria com a feta, la targeta es mou de la columna «Pendents» a «Fetes» sense destruir-se, els comptadors passen de 3 tasques · 25 h a 2 tasques · 20 h i d'1 tasca · 3 h a 2 tasques · 8 h, el resum baixa de 45 a 40 h obertes i d'1 vençuda a 0, i el focus continua exactament on era.

• Interpolar dades sense escapar en una plantilla de text. N'hi ha prou amb un ${} oblidat per obrir un XSS. Si tries aquest enfocament, escapa sempre; si pots, fes servir <template> o nodes i elimina la classe sencera d'errors.
• Fer servir l'índex de l'array com a clau. data-id="${index}" sembla que funciona fins que s'elimina un element del mig: llavors tots els nodes representen la dada equivocada. La clau ha de pertànyer a la dada.
• Oblidar ?? [] amb Object.groupBy. Només crea les claus que apareixen; una columna sense tasques dona undefined i el .map següent llança TypeError.
• Ordenar l'array del model. sort muta. Funciona aquí perquè tauler.tasques retorna una còpia; si algun getter retornés l'array intern, estaries reordenant el model des de la vista. Davant del dubte, [...llista].sort(...).
• Redibuixar dins d'un bucle d'esdeveniments ràpid. Un render() complet per cada pulsació de tecla en un camp de cerca és feina malgastada. La solució és el debounce que veuràs a 06-07.
• Posar gestors dins de render. Si render registra gestors, cada crida n'afegeix un altre i acabes amb l'acció executant-se cinc vegades. Els gestors es registren una vegada, per delegació, fora del render.
• Redibuixar i perdre el focus sense adonar-se'n. És una fallada d'accessibilitat seriosa i silenciosa: qui fa servir ratolí no la nota mai. Prova-ho sempre amb el tabulador.
• Consell: mantén render() sense efectes ocults. Que només llegeixi l'estat i escrigui al DOM. Si fa peticions, canvia el model o dispara accions, deixa de ser predictible i depurar es torna molt difícil.
• Consell: desa l'estat de la vista en un sol objecte. Tenir filtres, ordre i avui en un únic #estat fa trivial respondre a «per què es veu això?»: imprimeixes l'objecte i ho saps.

Afegeix a l'HTML un <input type="search" id="cercar"> amb la seva <label> i connecta'l perquè en escriure es filtrin les tasques per títol. Ha de fer servir estat.filtres.text, no tocar el model, i mostrar al resum quantes se n'estan veient. Comprova amb el tabulador que el focus no surt del camp de cerca en escriure, i explica per què la reconciliació és imprescindible aquí.

Afegeix un <select id="ordre"> amb les opcions prioritat, data límit i hores, i fes que en canviar-lo es reordenin les targetes. Després comprova, amb les DevTools, que en reordenar els nodes es mouen en lloc de recrear-se: posa un data-marca en un <li> des de la consola, reordena, i verifica que la marca continua allà.

Afegeix un botó data-accio="eliminar" a la targeta i un mètode eliminar(id) al Tauler. Comprova que després d'eliminar una tasca del mig, les targetes restants conserven els seus nodes (no es recreen) i que el focus passa al botó equivalent de la tasca següent. Explica què hauria passat si reconciliar fes servir la posició en lloc de data-id.

Exercici 1

La reconciliació és imprescindible aquí per un motiu molt concret: l'esdeveniment input es dispara a cada pulsació, així que cada lletra provoca un render(). Si aquell render fes replaceChildren, destruiria i recrearia totes les targetes vint vegades mentre la Marta escriu «serigrafia». No perdria el focus de l'<input> —és fora del contenidor reconciliat—, però sí que malgastaria moltíssima feina, reiniciaria les transicions CSS a cada tecla i produiria un parpelleig perfectament visible. Amb reconciliar, cada pulsació només elimina les targetes que deixen de coincidir i retorna les que hi tornen a coincidir.

Escrivint «fust», el resum mostra 6 tasques · 5 obertes · 45 de 48 h · 1 vençuda · esforç 124 · mostrant-ne 1: els números del model no canvien, només el compte del que es mostra. És exactament la separació que buscàvem.

Exercici 2

Comprovació que els nodes es mouen i no es recreen:

Si la marca sobreviu, és que reconciliar va reutilitzar el node i només el va recol·locar amb insertBefore. Amb replaceChildren la marca hauria desaparegut, perquè el <li> seria un altre objecte diferent. Aquest truc de l'atribut testimoni és, per cert, una tècnica de depuració excel·lent per verificar qualsevol estratègia de reutilització de nodes.

Nota: change és l'esdeveniment adequat per a un <select>; input també funciona, però change expressa millor la intenció de «ha triat una opció».

Exercici 3

Si reconciliar identifiqués els nodes per posició, en eliminar la tasca del mig passaria el següent: el node que ocupava la posició 2 s'ompliria amb les dades de la tasca que abans era a la 3, el de la 3 amb els de la 4, i així fins al final; l'últim node s'eliminaria. Visualment el resultat seria correcte, però tots els nodes haurien canviat de dada: el focus, que era a la targeta de la posició 3, acabaria en una targeta que ara mostra una altra tasca; qualsevol transició CSS en curs s'aplicaria a l'element equivocat; i qualsevol estat del navegador lligat a un node (un <details> desplegat, per exemple) s'atribuiria a la tasca que no era.

Amb data-id com a clau, el node de cada tasca continua sent seu passi el que passi: només s'elimina el node la clau del qual desapareix de les dades. És exactament per això que React, Vue i Angular insisteixen tant en la prop key de les llistes, i veure-ho des de dins t'estalviarà molt de temps quan arribis al Mòdul 10.

Has passat de manipular nodes solts a tenir una arquitectura. L'eix és la funció render(estat), que descriu com ha de veure's la pantalla donat un estat, i el cicle estat → render → esdeveniment → estat nou → render, amb les seves regles: un sol sentit, els gestors no toquen el DOM (canvien l'estat i criden render), i el model continua sense saber que existeix una pantalla. L'avantatge no és escriure menys, sinó que la interfície no es pot desincronitzar de les dades, que és la classe d'error més difícil de perseguir en una aplicació imperativa.

Coneixes les tres maneres de produir HTML i el criteri per triar. Els template literals són els més llegibles i els més perillosos: exigeixen escapar cada dada amb una funció escaparHtml que tradueixi & < > " ', i n'hi ha prou amb un oblit per obrir un XSS. La construcció amb nodes és segura per definició. I <template> amb content.cloneNode(true) combina la llegibilitat de tenir l'estructura a l'HTML amb la seguretat d'omplir mitjançant textContent, que és l'opció adoptada al projecte. Sobre ella has escrit pintarTargeta(tasca, existent), una funció que crea o actualitza segons li passis o no un node previ: la propietat que fa possible tota la resta.

Saps agrupar el tauler per columnes amb Object.groupBy, amb el recordatori que només crea les claus presents i que cal ?? []; dibuixar comptadors per columna (3 tasques i 25 h pendents, 2 i 20 h en curs, 1 i 3 h fetes, que sumen les 45 h obertes de sempre); i tenir cura dels estats buits amb missatges diferents segons sigui una columna buida, un filtre sense resultats o un tauler acabat d'estrenar. I, sobretot, saps què passa quan es redibuixa tot amb replaceChildren: es perden el focus, el desplaçament, la selecció i l'estat del navegador, una fallada d'accessibilitat que qui fa servir ratolí no percep mai. La resposta són les claus estables: reconciliar(contenidor, dades, clau, pintar) indexa els nodes existents en un Map pel seu data-id, reutilitza els que continuen vius actualitzant-ne el contingut, els recol·loca amb insertBefore i elimina els sobrants. Els nodes supervivents conserven la seva identitat, i amb ella el focus i les transicions. Filtrar i ordenar, finalment, són decisions de la vista: viuen al seu estat, operen sobre la còpia que retorna tauler.tasques i no alteren mai el model.

Aquell reconciliar de vint línies és també una lliçó sobre l'ofici: fer-ho bé per a una llista plana amb clau és assequible; fer-ho per a arbres imbricats de components, amb ordre arbitrari i actualitzacions parcials, és la feina que fan React, Vue i Angular. Arribaràs al Mòdul 10 sabent exactament quin problema resolen i per què tots et demanen una key.

Queda una última peça, i és la que converteix el tauler en una eina de debò. La Marta pot moure tasques i filtrar-les, però no en pot crear cap: el backlog continua sent el de dades/backlog.js. Donar d'alta una tasca significa un formulari, i un formulari porta un món propi: camps accessibles amb les seves etiquetes, valors que arriben sempre com a text, validació nativa del navegador davant de validació en JavaScript, regles de negoci que han de continuar vivint al model, missatges d'error que un lector de pantalla pugui anunciar, i el focus posat on toca quan alguna cosa falla. Tot això és Gestió i Validació de Formularis, l'última lliçó del mòdul.