Tens el pla, el model de dades, les regles R1–R15 i un repositori verd amb la pàgina buida. Ara cal omplir-la, i la pregunta que decideix si el projecte avança o s'encalla no és «què escric?», sinó «per on començo?». La resposta intuïtiva —obrir index.html i maquetar la pantalla, perquè és l'única cosa que es veu— és exactament l'equivocada, i és la raó per la qual tants projectes personals tenen una interfície preciosa a sobre d'una lògica que no es pot provar ni canviar. En aquesta lliçó aprendràs l'ordre que funciona: de dins cap a fora —domini, dades, vista, aplicació— i vertical abans que horitzontal, una funcionalitat completa de punta a punta abans que totes les capes a mitges. Veuràs com construir el domini amb TDD sobre les regles noves, com resoldre l'arbre de subtasques amb la recursivitat de 03-07, com muntar una capa de dades en memòria que no et bloquegi i que deixi la frontera llesta per a la lliçó següent, com escriure components de vista sense framework amb el cicle estat → render → esdeveniment, com governar l'estat amb una única font de veritat i actualitzacions immutables, com fer accessible l'aplicació des del primer commit en lloc de al final, i com gestionar i registrar els errors de tot el sistema. I acabaràs amb dues coses que no són codi però decideixen el ritme del projecte: una llista de comprovació de qualitat per tancar cada increment, i un mètode concret per quan t'encalles — perquè t'encallaràs.

1. De dins cap a fora: per què aquest ordre
2. Vertical abans que horitzontal
3. L'ordre de treball recomanat
4. El domini: entitats i invariants
5. TDD sobre les regles R11 a R15
6. L'arbre de subtasques amb recursivitat
7. La capa de dades: el repositori en memòria primer
8. El contracte del repositori com a frontera
9. L'estat de l'aplicació: una única font de veritat
10. Actualitzacions immutables i esdeveniments
11. La vista sense framework: estat → render → esdeveniment
12. Delegació d'esdeveniments i el controlador
13. El formulari accessible
14. Les tres pantalles noves
15. Accessibilitat des del principi
16. Registre i gestió d'errors de tota l'aplicació
17. Increments verificables i commits petits
18. Quan refactoritzar i com no trencar res
19. La llista de comprovació abans de tancar un increment
20. Què fer quan t'encalles
21. Errors Habituals i Consells
22. Exercicis
23. Conclusió

Hi ha dues maneres de construir una aplicació, i l'elecció determina gairebé tota la resta.

De fora cap a dins és la intuïtiva: es comença per l'HTML i el CSS, perquè és el que es veu i el que dona sensació d'avenç. Quan la pantalla és bonica, s'hi afegeix JavaScript perquè els botons facin alguna cosa. Quan els botons fan alguna cosa, es desa a localStorage. I la lògica de negoci acaba repartida entre els gestors d'esdeveniments, perquè és on es necessitava.

De dins cap a fora és la que faràs servir: es comença pel domini —les entitats i les regles—, després les dades, després la vista, i per últim l'aplicació que ho uneix. Durant els primers dies no hi ha res per ensenyar al navegador, i això incomoda.

La comparació honesta:

L'última fila és la decisiva. Els errors de model són els més cars que existeixen, perquè contaminen tot el que s'hi recolza. Si descobreixes el dia 2 que horesEstimades no pot ser un camp editable en una tasca amb filles (R12), canvies tres funcions. Si ho descobreixes a la setmana 5, canvies tres funcions, dues vistes, un formulari, l'informe, la persistència i les dades que ja van desar els teus usuaris de prova.

I hi ha un argument addicional del mateix curs: a 10-06 va quedar demostrat que domini/regles.js va ser idèntic a les quatre versions de la mateixa pantalla. El domini és la part del projecte amb més valor i més vida útil. Construir-lo primer és construir primer el que més dura.

L'objecció raonable, i la seva resposta. «Si no veig res durant tres dies, perdo la motivació». És un problema real i té dues solucions concretes:

1. Les proves en verd són la teva pantalla. Veure 47 passed amb les regles del domini cobertes és exactament el mateix senyal d'avenç que veure una llista pintada. Canvia el que compta com a progrés.
2. L'apartat 2 escurça aquests dies dràsticament. No construeixes tot el domini abans de tocar la vista: construeixes el tall del domini que necessita la primera funcionalitat, i surts al navegador amb ell.

Aquest és el segon principi, i corregeix el perill del primer.

• Horitzontal vol dir acabar una capa sencera abans de passar a la següent: tot el domini, després totes les dades, després tota la vista.
• Vertical vol dir acabar una funcionalitat completa travessant les quatre capes abans de començar la següent.

Per què vertical guanya, amb tres raons que no són d'estil:

1 · Valida l'arquitectura aviat. El primer tall vertical és el que revela si les teves fronteres funcionen. Si en pintar la primera llista descobreixes que necessites importar dades/ des de vista/, tens un problema de disseny — i el tens el dia 3, quan canviar-lo costa una hora.

2 · Produeix alguna cosa lliurable en tot moment. Al final de cada tall, l'aplicació funciona. Amb menys funcionalitats, però funciona. Si el projecte s'interrompés demà, tindries un producte petit en lloc de tres capes incompletes que no arrenquen.

3 · Descobreix els requisits ocults. Cada tall complet treu a la llum coses que el pla no contemplava: què passa si la llista és buida, on va el focus després de crear una tasca, què es mostra mentre carrega. Descobrir-les d'una en una és manejable; descobrir-ne trenta alhora a la setmana 6 és aclaparador.

El primer tall vertical d'Òrbita —el que cal fer literalment primer— és aquest:

Veure el tauler amb les tasques d'exemple. Sense crear, sense editar, sense filtrar. Només: les dades de llavor arriben del repositori en memòria, es construeixen entitats del domini, i es pinten en una llista accessible.

Sembla poc. Travessa les quatre capes, obliga a definir el contracte del repositori, el format de l'estat, l'estructura de la vista i el punt d'entrada. Quan aquest tall funciona, l'esquelet del projecte sencer està decidit i provat.

Combinant els dos principis, aquest és l'ordre concret de les fites H2 i H3, amb les hores estimades del pla de 11-01:

Fixa't en el patró: tres increments de domini pur al principi (els tres primers, 12 hores) i a partir d'aquí talls verticals. Aquest arrencament de domini no és horitzontalisme: és la porció mínima sense la qual el primer tall no té què pintar.

I fixa't en l'increment 7, que és de domini pur enmig dels talls. És correcte: quan una funcionalitat té lògica de negoci complexa —l'arbre— convé resoldre-la i provar-la al domini abans d'exposar-la. Depurar un cicle en un arbre a través de la interfície és un malson; depurar-lo en una prova unitària és trivial.

Un invariant és una afirmació sobre un objecte que és certa sempre, des que es crea fins que es destrueix. «Una tasca sempre té títol no buit» és un invariant. «Una tasca de vegades té títol» no ho és.

La idea que fa que el domini valgui la pena és aquesta:

Si un objecte no pot existir en estat invàlid, la meitat dels teus errors no poden ocórrer.

Això s'aconsegueix amb dues tècniques que ja coneixes de 05-02 i 05-03: validar al constructor i encapsular l'estat mutable.

Aquest és l'esquelet de src/domini/tasca.js. No és el codi complet: és el contracte que has d'omplir, amb els punts de decisió marcats.

Cinc decisions incrustades en aquest esquelet que convé entendre bé:

1 · Validar-ho tot abans d'assignar res. Si valides i assignes alternant, un error a mitges deixa l'objecte mig construït. En JavaScript el constructor que llança no retorna objecte, així que tant és a la pràctica… excepte si el constructor ja ha modificat alguna cosa externa (un comptador d'ids, per exemple). Valida primer, sempre.

2 · Normalitzar a la frontera. El títol arriba amb espais, les etiquetes amb majúscules, el responsable com a ''. El domini els normalitza una vegada, en entrar, i a partir d'aquí tot el codi pot confiar en el format. És la mateixa idea que R8 i R9 defensaven des del Mòdul 1.

3 · Congelar l'immutable. Object.freeze(this.etiquetes) evita que algú faci tasca.etiquetes.push('X') saltant-se R9. És barat i tanca una classe sencera d'errors.

4 · avui com a paràmetre. Aquesta és la decisió que més agrairàs a 11-04. Si estaVencuda() crida Date.now(), la prova «una tasca del 5 de setembre està vençuda» funciona avui i falla el dia que canviïs la dada d'exemple. Passant avui, la prova és determinista per sempre. La mateixa tècnica serveix per al generador d'ids i per a qualsevol font de no determinisme: s'injecta, no s'invoca.

5 · canviarEstat retorna el canvi. No retorna void ni this: retorna un objecte { camp, abans, despres } que la capa d'aplicació farà servir per construir l'entrada d'historial (R14). Així el domini no necessita saber que existeix un historial, i l'historial no necessita saber com es calcula un canvi.

Tenir les regles en constants amb nom, en un únic fitxer, produeix tres beneficis immediats:

• Es llegeixen com a documentació. Algú que obri regles.js entén el negoci en dos minuts.
• Canviar-les és canviar una línia. Si el màxim passa de 40 a 45 hores, hi ha un sol lloc.
• Les proves les poden importar. I això evita l'error clàssic d'escriure 40 a mà a la prova: si la regla canvia, la prova canvia sola amb ella… la qual cosa és bona per als límits i dolenta per als valors d'exemple. Sigues conscient de quin estàs fent servir en cada cas.

TDD (Test-Driven Development, desenvolupament guiat per proves) és el cicle que 08-03 va introduir: vermell → verd → refactoritzar. Escrius una prova que falla, escrius el codi mínim que la fa passar, i després netges.

No tot el projecte es fa amb TDD, i dir-ho és més honest que fingir el contrari. Però hi ha una part on compensa moltíssim:

Aquest és un cicle complet, tal com l'has d'executar. Vermell primer:

Quatre proves, i cap no és redundant:

• La primera comprova que falla.
• La segona comprova que el missatge serveix a l'usuari. Un ErrorDeRegla amb el text «Operació no permesa» és inútil a la interfície. Provar el missatge obliga a escriure'l bé.
• La tercera comprova el camí feliç i, de passada, l'objecte de canvi que necessita R14.
• La quarta comprova el cas degenerat: sense subtasques, la regla no ha de destorbar. És el cas que més sovint es trenca en implementar la regla amb massa entusiasme.

Les funcions auxiliars (crearTascaEnCurs, tascaFeta, tascaPendent) són el secret d'una suite llegible. Construir una Tasca vàlida requereix sis camps; repetir-los en quaranta proves fa que no se'n llegeixi cap. Escriu un fitxer test/ajudes/fabriques.js amb constructors que rebin només el que la prova vol destacar i omplin la resta amb valors per defecte vàlids. És mitja hora de feina que s'amortitza a la tercera prova.

R6 té 3 estats × 3 destins = 9 combinacions, de les quals 4 són vàlides. Escriure nou proves gairebé idèntiques és soroll; test.each de Jest ho resol:

La taula és l'especificació. Si algú pregunta quines transicions són vàlides, aquestes nou línies ho responen millor que qualsevol document, i a més estan verificades.

Consell important sobre la cobertura de regles: per a cada regla, escriu sempre almenys el cas que sí que passa, el cas que no passa, i el cas límit exacte. Per a R3 (horesEstimades de 0 a 40): 0 rebutjat, 0.5 acceptat, 40 acceptat, 40.1 rebutjat. Les errades viuen als marges, no al mig.

Aquesta és la part del domini amb més substància tècnica i la que reprèn directament la lliçó 03-07. Recorda la decisió de 11-01: l'arbre es desa pla (cada tasca amb tascaMareId) i es construeix en memòria quan cal.

Dos detalls que separen una implementació correcta d'una que funciona per casualitat:

• El Map per id converteix la construcció en una sola passada. Amb tasques.find(...) dins del bucle, el cost seria quadràtic: irrellevant amb 6 tasques, perceptible amb 600 (que és exactament l'escenari de 09-01).
• La mare inexistent llança ErrorDeDades, no s'ignora. Si una dada desada apunta a una mare esborrada, vols assabentar-te'n, no que la tasca desaparegui en silenci de la interfície. Aquest cas passarà de debò a la lliçó 11-03, quan migris dades.

I la detecció de cicles, que és la regla que més gent implementa malament:

Les tres condicions són diferents i cal provar-les per separat:

1. Autoreferència: A no pot ser mare d'A. És el cas trivial i l'únic que tothom comprova.
2. Cicle indirecte: si A és mare de B i B de C, C no pot ser mare d'A. És el que s'oblida, i produeix un desbordament de pila així que algú pinta l'arbre.
3. Profunditat: vincular un subarbre de 2 nivells sota un node que ja és al nivell 2 donaria 4. Aquest també s'oblida, perquè la comprovació ingènua només mira el node, no el subarbre sencer.

Compte amb la recursivitat i la pila. Amb profunditat màxima 3 no hi ha cap risc. Però si el teu domini permet arbres arbitràriament profunds (una categoria d'inventari, per exemple), un cicle no detectat produeix recursió infinita i RangeError: Maximum call stack size exceeded. La lliçó 03-07 explicava l'alternativa iterativa amb pila explícita; tingues-la present si el teu domini no acota la profunditat.

Aquí hi ha una temptació forta que convé desactivar ja: començar per localStorage perquè «així ja persisteix». No ho facis. Comença amb un repositori en memòria, per quatre raons molt concretes:

1. No et bloqueja. Serialitzar, migrar formats i gestionar quotes són problemes reals que mereixen una lliçó sencera — la següent. Resoldre'ls ara t'aparta del que estàs construint.
2. Les proves són instantànies i netes. Un repositori en memòria es crea nou a cada prova. Amb localStorage, cada prova arrossega l'estat de l'anterior tret que netegis, i aquell beforeEach que s'oblida és una font clàssica de proves intermitents.
3. Obliga a definir la frontera. Si escrius primer la implementació fàcil, el contracte queda clar; si escrius primer la difícil, el contracte acaba contaminat amb detalls de localStorage (claus, JSON.stringify, quotes) que no n'haurien de sortir.
4. És la implementació que faran servir les teves proves per sempre. No és codi rebutjable: RepositoriMemoria continuarà viu a la suite de 11-04 com a doble de prova.

Per què async si tot és a la memòria? Perquè el contracte ha de ser el mateix que el del repositori d'API de la lliçó 11-03, on l'asincronia és inevitable. Si el repositori en memòria fos síncron, tota la capa d'aplicació estaria escrita en estil síncron i canviar-la després significaria reescriure-la sencera. Dissenya la frontera per a la implementació més exigent, no per a la més còmoda. És una de les decisions més rendibles de tot el projecte i costa zero.

La llavor. src/dades/llavor.js conté les dades fictícies d'arrencada: tres o quatre usuaris inventats i vuit o deu tasques que incloguin almenys un cas límit de cada regla nova — una tasca vençuda (R10), una amb subtasques mixtes (R13), un usuari inactiu amb tasques assignades (R11), una persona per sobre de 40 h en una setmana (R7/R15). Així, cada vegada que obris l'aplicació, els casos interessants són al davant i no els has de fabricar a mà.

src/dades/repositori.js no conté implementació: conté el contracte, documentat.

Les sis regles del contracte no són burocràcia; cadascuna evita un problema concret:

La prova de contracte és la tècnica que fa que això funcioni de debò: una única bateria de proves que s'executa contra les tres implementacions.

A la lliçó 11-03 cridaràs aquesta mateixa funció amb RepositoriLocal i RepositoriApi, i si les tres passen, són intercanviables. És la garantia que fa possible que canviar d'emmagatzematge sigui canviar una línia a main.js. Escriu-la ara, amb la implementació en memòria, encara que sembli excessiva per a un sol cas: en dues lliçons t'estalviarà el dia sencer.

Aquí hi ha l'error de disseny més comú en aplicacions sense framework, i convé veure'l amb nom i cognoms: l'estat repartit. El filtre actiu viu en una variable de la barra de filtres, les tasques visibles en un array de la vista de tauler, l'usuari actual en un atribut data- de la capçalera, i el mode del formulari en una propietat del mateix formulari.

Funciona. Fins al dia que dos d'aquests llocs deixen de coincidir, i llavors tens una interfície que mostra «12 tasques» sobre una llista de 9, i no hi ha manera de saber quin dels dos menteix.

La regla que ho evita:

Un sol objecte conté tot el que la interfície necessita per pintar-se. Res més no governa el que es veu.

Tres coses que sí que van a l'estat i sovint s'obliden:

• carregant i error. Tota operació asíncrona té tres desenllaços i la interfície ha de poder pintar-los tots tres. Si no són a l'estat, acabaran com a variables soltes i com a interfícies que es queden penjades.
• pantalla. La navegació és estat, no una conseqüència lateral de l'encaminador. L'encaminador tradueix la URL a estat i a l'inrevés; no és la font de veritat.
• filtres complet, amb el seu mode. És el que permet complir el criteri 3 d'H-07: serialitzar el filtre a la URL i restaurar-lo.

I una que no hi va: les dades derivades. tasquesVisibles, horesObertes o tasquesPerPersona es calculen a partir de l'estat, no es desen dins seu. Desar-les crea dues fonts de veritat, que és exactament el problema que estem evitant. Si el càlcul és car, es memoïtza (09-02), però es continua calculant.

Aquestes funcions s'anomenen selectors i tenen tres avantatges: són pures (es proven sense muntar res), es componen entre elles, i són el lloc natural on memoïtzar si el rendiment ho demana. És el mateix concepte que 10-03 presentava a Redux, aquí sense cap llibreria: quaranta línies pròpies.

L'estat se substitueix, no es modifica. Cada acció produeix un estat nou a partir de l'anterior, amb la desestructuració i el spread de 04-07:

Cinc decisions en vint línies:

1 · Object.freeze a cada actualització. Converteix en error qualsevol intent de mutar l'estat directament (en mode estricte, que ja fas servir). És una barana barata que detecta l'error on passa.

2 · versio s'incrementa sempre. Serveix per depurar («quantes actualitzacions porto?») i per detectar renderitzats innecessaris. És la mateixa idea del comptador de versió que invalidava la memòria cau del Tauler de Nómada Tasques.

3 · Els subscriptors reben l'estat anterior. Sense ell, una vista no pot saber què ha canviat i ha de repintar-ho tot. Amb ell, pot comparar i actualitzar només el necessari, que és la base de l'actualitzar() de 09-04.

4 · subscriure retorna la funció de baixa. Aquest detall val una fuita de memòria. Si subscriure's no retorna com donar-se de baixa, les vistes destruïdes continuen al Set per sempre retenint el seu DOM: exactament la fuita que vas estudiar a 09-03. Retornant la baixa, destruir() és una línia.

5 · Actualització superficial. { ...estat, ...canvi } fusiona un nivell. Per canviar un filtre cal escriure filtres: { ...estat.filtres, etiquetes: [...] }, la qual cosa és una mica verbosa però explícita. Resistir la temptació d'una fusió profunda «màgica» és correcte: la fusió profunda amaga què s'està canviant i produeix sorpreses amb arrays.

Com encaixa amb els esdeveniments de 06-04. Hi ha dos mecanismes i fan coses diferents; convé no barrejar-los:

La vista emet una intenció ({ accio: 'canviar-estat', id: 4, a: 'feta' }), l'aplicació executa el cas d'ús, el cas d'ús crida el domini i el repositori, i el magatzem notifica l'estat nou. És un cicle unidireccional, i aquesta unidireccionalitat és la raó per la qual s'hi pot raonar.

Aquest diagrama és tota l'arquitectura de la teva aplicació. Si el pots dibuixar de memòria, el pots explicar en una entrevista (lliçó 11-06).

Un component de vista sense framework té una forma molt concreta, i convé que tots els del teu projecte la comparteixin. Aquesta és la plantilla:

Quatre exigències d'aquesta forma:

1 · Rep el seu contenidor, no el busca. Un component que fa document.querySelector('#tauler') a dins només pot existir una vegada i només funciona si aquell id existeix. Rebent-lo, es pot muntar dues vegades, en un fragment, o a jsdom durant una prova (08-05).

2 · Rep enEmetre, no importa l'aplicació. És la frontera de l'apartat 10 de 11-01 feta codi: la vista no sap què passa quan emet, només que algú escolta. Això és el que permet provar-la amb un jest.fn() en lloc de amb l'aplicació sencera.

3 · Separa render d'actualitzar. render construeix; actualitzar reconcilia. Repintar-ho tot a cada canvi és el que portava render() a 310 ms amb 600 tasques a 09-01; reconciliar per data-id és el que ho va baixar a 31 ms a 09-04. Si el teu projecte tindrà llistes llargues, la separació és obligatòria; si no, continua sent bona disciplina.

4 · Té destruir() i es fa servir. Cada escolta afegida, cada setInterval, cada subscripció i cada IntersectionObserver es desfà allà. Sense això, navegar entre pantalles perd memòria — i a 11-04 et tocarà depurar exactament aquesta fuita.

Plantilles amb <template>. Per a l'estructura repetida (la fila de tasca), fes servir <template> a l'HTML i cloneNode(true), com a 06-06. És més ràpid que construir amb createElement node a node i, sobretot, manté l'estructura visible a l'HTML on es pot revisar la semàntica.

No facis servir mai innerHTML amb dades de l'usuari. Un títol de tasca que contingui <img src=x onerror=alert(1)> s'executa. Fes servir textContent per a tot el que vingui de dades, i innerHTML només amb literals teus. És la lliçó de 06-02, i a 11-03 hi tornarem perquè així que les dades vénen d'una API el risc es multiplica.

Amb 600 tasques i tres botons cadascuna, afegir escoltes individuals significa 1.800 escoltes. La delegació de 06-04 ho resol amb una:

Quatre detalls del codi que importen:

• closest('[data-accio]') troba el botó encara que el clic caigui sobre una icona a dins seu. Sense això, la meitat dels clics no fan res i l'errada és intermitent i desconcertant.
• arrel.contains(disparador) evita actuar sobre elements que ja no són a l'arbre (pot passar si el DOM va canviar entre el clic i el gestor).
• L'identificador es llegeix de data-id, l'única font de veritat sobre a quina fila correspon l'esdeveniment. Res d'índexs d'array: canvien en filtrar.
• Retorna la funció de baixa. Un altre cop. És un patró, no una casualitat: tot el que es connecta ha de poder desconnectar-se.

La delegació i el teclat. Un click en un <button> es dispara també amb Enter i amb Espai: el navegador ho fa per tu. Aquesta és la raó pràctica —i no estètica— per la qual un <div> clicable està malament: obliga a afegir tabindex, role="button" i un gestor de teclat propi per replicar el que l'element correcte ja fa. L'accessibilitat gairebé sempre és menys feina, no més.

El formulari és on es concentren els errors d'accessibilitat i on el domini demostra que serveix. La regla que ho governa tot:

La validació del formulari i la del domini són la mateixa. El formulari l'anticipa; el domini la decideix.

A la pràctica, això significa que el formulari crida el domini i tradueix els seus errors, en lloc de duplicar les regles:

Aquest error.camp és la raó per la qual ErrorDeValidacio porta aquesta propietat des del Mòdul 5: permet que la vista sàpiga quin camp marcar sense analitzar el missatge.

La llista de comprovació d'un formulari accessible, que has de complir a tots:

Els punts 4, 5 i 10 són els que gairebé mai no s'implementen en projectes de portafoli i els que més es noten en una revisió d'accessibilitat (11-04).

Les extensions E4, E5 i E6 de 11-01 produeixen tres pantalles que no són llistes de targetes, i aquí hi ha el seu valor formatiu: són les primeres que no pots resoldre copiant TaulerVista.

El càlcul del primer dia de la graella i del nombre de setmanes és el clàssic exercici de dates: escriu-lo a util/dates.js com a funció pura i prova'l amb febrer d'un any de traspàs, amb un mes que comença en diumenge i amb el canvi d'any. Aquests tres casos cobreixen gairebé totes les errades possibles.

Aquest detall de l'usuari esborrat és una decisió de modelatge que potser no havies anticipat: si l'entrada d'historial desa només usuariId i aquest usuari es desactiva o desapareix, l'historial perd llegibilitat. Desar també el nom en el moment del canvi és duplicació deliberada, i és el correcte en dades històriques. Anota-ho com a ADR (11-06).

L'argument definitiu per no deixar-la per al final és de cost:

I bona part d'aquest 5 % es redueix a fer servir l'element HTML que ja existeix:

Aquest últim mereix èmfasi: <dialog> amb showModal() resol tot sol l'atrapament de focus, el tancament amb Escape i la inertització del fons. Reimplementar això a mà són cent línies fràgils.

Llista de comprovació d'accessibilitat per increment (va a la Definició de Fet de 11-01):

Els dotze punts es comproven en uns cinc minuts per pantalla. Fes-ho en tancar cada increment, no al final del projecte.

La regió d'anuncis és una de sola, viva des de l'arrencada, i la fa servir tota l'aplicació:

El truc de buidar i tornar a posar al fotograma següent és necessari perquè molts lectors de pantalla no anuncien un text idèntic a l'anterior. Sense ell, «Tasca creada» s'anuncia la primera vegada i cap més.

El teu projecte té tres tipus d'error, i cadascun es tracta diferent:

La distinció no és acadèmica: els dos primers són comportament esperat i no han d'embrutar el registre d'errors. Si registres cada validació fallida, el registre s'omple de soroll i les errades reals s'hi perden.

Cinc punts del patró, que has de repetir a tots els casos d'ús:

1. carregant: true i error: null en començar. Netejar l'error anterior evita que quedi penjat un missatge de fa dues operacions.
2. try/catch al voltant de tot, amb carregant: false al catch. Un carregant que no s'apaga és un comptador girant per sempre.
3. aErrorInterficie(error) tradueix un error tècnic a alguna cosa que una persona entén. És responsabilitat de l'aplicació, no del domini ni de les dades.
4. Només es registren els tècnics.
5. Es rellança l'error. Qui l'ha cridat (el formulari) necessita saber que ha fallat per no tancar-se ni netejar els camps.

El registrador, minimalista i suficient:

I les dues xarxes de seguretat globals, a main.js:

La segona és la que més errades silencioses caça: una promesa rebutjada sense catch no apareix enlloc excepte a la consola, i en producció ningú no mira la consola dels seus usuaris.

Avís de privacitat al registre. El camp context és temptador per posar-hi «les dades que van causar l'errada». No hi posis mai dades personals, tokens ni contingut escrit per l'usuari. Registra identificadors i noms de camp ({ cas: 'crearTasca', camps: ['titol', 'horesEstimades'] }), no valors. Quan a 11-05 connectis un servei de seguiment d'errors en producció, aquesta disciplina serà una obligació legal, no una recomanació.

Un increment verificable és un tros de feina que compleix tres condicions:

1. L'aplicació continua funcionant en acabar-lo.
2. Es pot demostrar amb alguna cosa: una prova nova en verd o un comportament visible.
3. Cap en mig dia o menys.

Comparació de dues maneres d'abordar la història H-04 (subtasques), amb la mateixa quantitat de feina:

L'argument de git bisect mereix atenció: és l'ordre que troba automàticament quin commit va introduir una errada, provant la meitat de la història cada vegada. Amb commits de 40 línies et dona la causa exacta; amb commits de 640 et dona un rang on encara has de buscar. Aquesta eina només funciona bé si els teus commits són petits i cadascun deixa el projecte funcionant.

El ritme que funciona, i que pots cronometrar:

Uns 55 minuts per volta. Quatre voltes és una sessió de treball productiva, i acaba amb quatre commits que expliquen una història llegible.

Refactoritzar és canviar l'estructura interna del codi sense canviar-ne el comportament. Aquesta definició conté la regla més important:

No refactoritzis mai i afegeixis funcionalitat al mateix commit.

Si ho barreges, i alguna cosa es trenca, no saps si va ser el canvi d'estructura o el de comportament. Separats, el commit de refactorització té una propietat valuosíssima: totes les proves passaven abans i passen després, sense tocar cap prova. Si has de modificar proves, no estaves refactoritzant: estaves canviant comportament.

Quan refactoritzar, amb senyals objectius:

Aquesta última fila és la regla d'or: no es refactoritza codi sense proves. Si cal tocar alguna cosa sense cobertura, l'ordre és: escriure proves del que fa ara (encara que el que faci sigui estrany), veure-les en verd, i només llavors canviar l'estructura. Les proves són la xarxa; sense xarxa, no és refactorització, és reescriptura a cegues.

I la regla que evita l'altre extrem: no refactoritzis codi que funciona, que no tocaràs i que ningú no ha reportat. La refactorització té un cost i un risc, i només es justifica quan l'estructura actual t'està destorbant per a alguna cosa concreta que faràs ara. «És lleig» no és una raó suficient quan tens un pla amb fites per complir.

Cinc minuts per increment. És la versió operativa de la Definició de Fet de 11-01.

El punt 2 té un procediment concret que val la pena aprendre: desa el teu canvi de codi amb git stash deixant les proves noves, executa-les i comprova que fallen; recupera amb git stash pop i comprova que passen. Això demostra que la prova prova alguna cosa. Una prova que passa amb i sense el canvi no està provant res, i és més comú del que sembla.

T'encallaràs. No és una possibilitat: forma part de la feina, i saber-ne sortir és una habilitat tan tècnica com saber escriure un reduce.

Quan alguna cosa no funciona i portes més de quinze minuts, para de teclejar i respon per escrit:

1 · Què esperava exactament que passés?

No «que funcioni». Alguna cosa verificable: «esperava que carregaPerPersona(estat) retornés { 'u-1': 25 }». Si no ho pots formular així, el problema no és el codi: és que no saps què vols. I aquest és l'encallament de debò.

2 · Què passa en realitat?

Amb la dada al davant: «retorna { 'u-1': 25, 'u-2': undefined }». No «dona error», sinó el missatge exacte, la línia exacta, el valor exacte.

3 · Quina és la diferència més petita entre el que esperava i el que passa?

«Hi ha una clau de més, amb valor undefined». Aquesta frase acostuma a contenir la causa: si apareix una clau que no hi hauria de ser, alguna cosa està iterant sobre usuaris en lloc de sobre tasques assignades.

Aquest mètode resol, per experiència, més de la meitat dels encallaments sense executar res. Funciona perquè l'encallament gairebé mai no és «no sé programar això»: és «tinc tres suposicions barrejades i una és falsa». Escriure-les les separa.

Posa un temporitzador de 45 minuts. Si en sonar no has avançat, canvia d'estratègia obligatòriament:

El pas 5 no és rendir-se: és l'estratègia amb millor relació entre cost i resultat de les cinc. Una quantitat sorprenent d'encallaments es resolen a la dutxa de l'endemà, perquè el problema era una suposició fixa que només es deixa anar en deixar de mirar-la.

El pas 4 té nom propi —rubber duck debugging, depuració amb ànec de goma— i funciona per una raó concreta: explicar-ho en veu alta t'obliga a fer explícites les suposicions que estaves donant per bones. Moltíssimes vegades la frase es talla a mitges amb un «…ah, espera».

És la tècnica més potent de totes i la que menys es fa servir. Consisteix a construir l'exemple més petit possible que reprodueixi l'errada, fora de l'aplicació.

Procediment:

1. Nou fitxer de prova, test/aillat.test.js, amb només l'imprescindible.
2. Dades mínimes: dues tasques en lloc de quaranta.
3. Sense vista, sense repositori, sense estat: només la funció sospitosa.
4. Treu coses fins que deixi de fallar. L'última cosa que has tret hi està implicada.
5. Quan falli amb deu línies, la causa acostuma a ser òbvia.

Un exemple real d'aquest projecte:

Amb tres tasques, «retorna 30 en comptes de 15» diu immediatament que alguna cosa es compta dues vegades. Amb quaranta tasques i la interfície muntada, aquesta mateixa errada és «els números de l'informe estan estranys» i et pot costar una tarda.

I un benefici addicional que acostuma a passar desapercebut: aquesta prova aïllada es queda a la suite. En arreglar-ho, ja tens la prova de regressió escrita, de franc. És exactament el mètode que aplicaràs a les tres errades de la lliçó 11-04.

De vegades l'encallament no és tècnic. Aquests senyals indiquen que el problema és un nivell més amunt:

Començar per l'HTML perquè és el que es veu. És el parany més natural del món i produeix aplicacions amb la lògica de negoci repartida entre gestors de clic. Si la teva regla R13 viu dins d'un onclick, no es pot provar sense navegador, no es pot reutilitzar des de l'informe i desapareixerà el dia que canviïs la interfície. Domini primer, sempre.

Construir tot el domini abans de tocar el navegador. L'error oposat, i també real. Tres increments de domini i fora: fes el primer tall vertical. L'arquitectura només es valida quan la travessa alguna cosa de punta a punta.

Estat repartit per la interfície. El filtre a la barra, la llista a la vista, el mode al formulari. Funciona fins al dia que deixen de coincidir, i llavors no hi ha manera de saber quin menteix. Un objecte d'estat, i les vistes en llegeixen.

Mutar l'estat directament. estat.tasques.push(nova) no dispara cap subscripció, així que la interfície no se n'assabenta i apareix «no s'actualitza» sense causa aparent. Object.freeze al magatzem converteix aquest error silenciós en una excepció immediata: fes-lo servir.

Duplicar les regles al formulari. Si valides «màxim 40 hores» al formulari i al domini, tens dues veritats que es desincronitzaran. El formulari crida el domini i tradueix l'error; el número 40 apareix una sola vegada, a regles.js.

Oblidar destruir(). Cada vista que es munta i no es desmunta bé deixa escoltes i subscripcions vives. Amb dues pantalles no es nota; a la lliçó 11-04 apareixerà com una fuita de memòria en navegar i l'hauràs de buscar. Escriu destruir() alhora que render(), no després.

Llegir Date.now() dins del domini. Fa que les proves depenguin del dia en què s'executen i produeix errades que apareixen soles un dilluns. Passa avui com a paràmetre. La mateixa regla val per a Math.random() i per als ids.

Commits gegants. «feat: subtasques» amb 640 línies és impossible de revisar, de revertir i de bisecar. Si el missatge necessita una «i», són dos commits.

Refactoritzar i afegir funcionalitat alhora. Quan alguna cosa es trenqui, no sabràs quin dels dos va ser. I si has de tocar proves mentre refactoritzes, no estàs refactoritzant.

Consell · Escriu primer la funció auxiliar de proves. Mitja hora construint test/ajudes/fabriques.js fa que les teves cent proves següents es llegeixin en una línia cadascuna. És la inversió amb millor retorn de tot el mòdul.

Consell · Tingues sempre un increment «en verd» al qual tornar. Abans de començar alguna cosa arriscada, assegura't que l'últim commit funciona. Així, si et perds, git restore . et torna a terreny ferm en lloc de a un pantà de canvis a mitges.

Consell · Apunta les decisions a mesura que les prens. Un fitxer docs/decisions.md amb tres línies per decisió. A 11-06 el convertiràs en ADR formals, i agrairàs no haver de reconstruir de memòria per què l'arbre és pla.

Consell · Acaba la sessió deixant una prova escrita que falla. És el millor punt de represa que existeix: l'endemà saps exactament què estaves fent i què toca fer, sense rellegir res.

Aquests exercicis són les fites H2 i H3 del teu projecte: el domini amb les seves proves en verd i la primera funcionalitat completa de punta a punta.

Exercici 1 — El domini complet amb TDD.

Implementa src/domini/ sencer amb les seves proves, seguint el cicle vermell → verd → refactoritzar:

1. errors.js amb ErrorDeValidacio (amb .camp), ErrorDeRegla i ErrorDeDades, tots heretant d'Error i amb name correcte.
2. regles.js amb totes les constants: estats, prioritats, rols, matriu de transicions i límits.
3. tasca.js i usuari.js amb validació completa al constructor, camps privats per al que és mutable i toJSON/desDeJSON.
4. arbre.js amb construirArbre, fulles, horesTotals, profunditat, esDescendent i potVincular.
5. tauler.js amb les operacions de conjunt i els càlculs (resum, horesObertes, carregaPerPersonaISetmana).
6. Proves: cada regla R1–R15 amb cas que passa, cas que falla i cas límit. Les transicions amb test.each (9 combinacions). Els cicles de l'arbre amb els tres tipus: autoreferència, cicle indirecte i excés de profunditat.
7. test/ajudes/fabriques.js amb constructors d'entitats vàlides per defecte.
8. Cobertura del domini ≥ 90 % de branques.

Requisit estricte: el domini no pot importar res de dades/, vista/ ni aplicacio/, ni fer servir document, localStorage, fetch, Date.now() ni Math.random(). npm run lint ho ha de verificar (frontera configurada a 11-01).

Exercici 2 — El primer tall vertical.

Implementa «veure el tauler» de punta a punta:

1. RepositoriMemoria amb el contracte complet i la llavor fictícia (mínim 8 tasques amb un cas límit de cada regla nova).
2. test/dades/contracte-repositori.js amb almenys 8 proves de contracte, executades contra la implementació en memòria.
3. crearMagatzem amb obtenir, actualitzar, subscriure (que retorna la baixa) i congelació de l'estat.
4. Selectors purs: tasquesVisibles, horesObertes, resumPerEstat.
5. TaulerVista amb render, actualitzar i destruir, fent servir <template> i semàntica de llista.
6. Controlador amb delegació per [data-accio] i [data-id].
7. main.js que ho munta tot, carrega la llavor i pinta.
8. Regió aria-live funcionant i anunci del nombre de tasques visibles.
9. Prova d'integració amb Testing Library: consultar per rol (getAllByRole('listitem')) i comprovar el contingut.

Exercici 3 — Els dos talls següents i l'arbre.

1. Crear una tasca: formulari amb FormData, validació delegada al domini, aria-invalid i aria-describedby, focus al primer error, i anunci de l'èxit. Compleix els 10 punts de la llista de l'apartat 13.
2. Canviar d'estat: R6 aplicada des de la interfície, amb l'error de regla mostrat de manera comprensible i anunciat.
3. Subtasques: crear una subtasca, veure-la imbricada, i comprovar que R13 impedeix tancar la mare amb filles obertes, amb el missatge que anomena la subtasca.
4. Cadascuna a la seva branca, amb almenys quatre commits convencionals, i tancada amb la llista de comprovació de l'apartat 19.
5. Documenta a docs/decisions.md almenys tres decisions preses durant la implementació.

De nou, no hi ha codi de solució: hi ha criteris d'acceptació i rúbriques. Aquestes llistes són les que has de recórrer abans de donar-te per satisfet.

Criteris d'acceptació de l'exercici 1 — Domini

El criteri 12 és la prova definitiva que la teva arquitectura funciona. Configura Jest amb projectes separats: node per a domini, jsdom per a la resta. Si el domini necessita jsdom, has creuat la frontera sense adonar-te'n.

Rúbrica de l'exercici 1 (24 punts)

Llindar: 17/24, amb obligatòriament 3 a «Fronteres» i ≥ 2 a «Cobertura de regles».

Criteris d'acceptació de l'exercici 2 — Tall vertical

Criteris d'acceptació de l'exercici 3 — Talls 2, 3 i 4

Autoavaluació de la fita H3. Abans de passar a la lliçó següent:

Un «sí» a la segona pregunta (que és l'única formulada a l'inrevés) o un «no» a qualsevol de les altres són deute que la lliçó 11-03 multiplicarà. Arregla-ho ara.

Has construït l'esquelet real del teu producte, i ho has fet en l'ordre que aguanta.

Saps per què es construeix de dins cap a fora: perquè els errors de model són els més cars que existeixen i apareixen el dia 2 en una prova unitària en lloc de a la setmana 5 repartits per sis fitxers; perquè el domini es prova a Node en mil·lisegons; i perquè és la part amb més vida útil, com va demostrar que domini/regles.js fos idèntic a les quatre versions de 10-06. I saps per què això no significa horitzontalisme: vertical abans que horitzontal, un tall complet que travessi les quatre capes abans que totes les capes a mitges, perquè és el que valida l'arquitectura aviat, deixa alguna cosa lliurable en tot moment i treu a la llum els requisits ocults d'un en un.

Tens el domini construït sobre invariants: un objecte que no pot existir en estat invàlid elimina la meitat dels errors possibles. Validar-ho tot abans d'assignar res, normalitzar a la frontera, congelar l'immutable, injectar avui en lloc d'invocar Date.now() —cosa que fa les proves deterministes per sempre— i retornar l'objecte de canvi des de canviarEstat perquè l'historial de R14 no obligui el domini a saber que existeix un historial. Amb les regles en un únic regles.js que es llegeix com a documentació.

Saps aplicar TDD on compensa —les regles de negoci i els càlculs, no la maquetació ni l'exploració— i saps que els criteris Donat / Quan / Llavors de 11-01 es tradueixen a proves gairebé paraula per paraula. Tens les quatre proves de R13 —que falla, que el missatge serveix, que el camí feliç funciona, i que la regla no destorba sense subtasques—, les nou transicions parametritzades amb test.each com a especificació verificada, i la disciplina de provar sempre el cas que passa, el que no i el límit exacte, perquè les errades viuen als marges.

Tens l'arbre resolt amb la recursivitat de 03-07: construcció en una passada amb un Map per id, error explícit davant d'una mare inexistent, i les tres condicions de cicle que cal comprovar per separat —autoreferència, cicle indirecte i excés de profunditat—, de les quals només la primera és evident i les altres dues són les que produeixen desbordaments de pila.

Tens la capa de dades començada per on no bloqueja: un repositori en memòria que no és codi rebutjable —serà el teu doble de prova per sempre—, amb un contracte asíncron dissenyat per a la implementació més exigent i no per a la més còmoda, i una bateria de proves de contracte que a la lliçó següent executaràs contra localStorage i contra l'API per demostrar que són intercanviables.

Tens l'estat governat: una única font de veritat congelada, amb carregant i error a dins perquè tota operació asíncrona té tres desenllaços; dades derivades calculades per selectors purs i mai desades; actualitzacions immutables amb spread; subscripcions que retornen la seva baixa, que és la línia que separa una aplicació neta d'una amb fuites; i el cicle unidireccional vista → aplicació → domini → dades → magatzem → vista que pots dibuixar de memòria.

Tens vistes sense framework amb una forma comuna: reben el seu contenidor i el seu enEmetre, separen render d'actualitzar —els 310 ms davant dels 31 ms de 09-04— i tenen destruir() escrit alhora que la resta. Amb delegació per [data-accio] i closest, plantilles <template>, textContent per a tota dada d'usuari, i formularis que criden el domini en lloc de duplicar-ne les regles, amb els deu punts d'accessibilitat que gairebé ningú no implementa: focus al primer error, error anunciat, i el formulari que no es buida quan alguna cosa falla.

Saps fer les tres pantalles que no són llistes —un calendari que és una <table> de debò, un informe el càlcul del qual és un selector pur i el risc més gran del qual és comptar dues vegades les hores de l'arbre, i un historial sense ni un botó d'editar perquè la R14 és una promesa—, i saps que l'accessibilitat costa un 5 % des del principi i un 30 % al final, i que la major part d'aquest 5 % consisteix simplement a fer servir l'element HTML que ja existeix.

Tens una gestió d'errors amb tres categories que es tracten diferent, amb les validacions i les regles fora del registre perquè el soroll no tapi les errades reals, un patró de cas d'ús amb carregant, try/catch, traducció a llenguatge humà i rellançament, les dues xarxes de seguretat globals —inclosa la de promeses rebutjades, que és la que caça les errades silencioses— i la disciplina de no posar mai dades personals al context del registre.

I tens el ritme: increments de mig dia que deixen l'aplicació funcionant, commits petits que fan útil git bisect, la regla de no refactoritzar i afegir funcionalitat al mateix commit, els set senyals objectius de quan refactoritzar —i el de quan no—, la llista de dotze comprovacions per tancar un increment, i un mètode concret per als encallaments: les tres preguntes per escrit, la caixa de temps de 45 minuts amb canvi obligatori d'estratègia, i reproduir en aïllament, que converteix «els números de l'informe estan estranys» en «amb tres tasques retorna 30 en comptes de 15» i, de passada, et regala la prova de regressió.

La fita H3 està tancada: el domini en verd i la primera funcionalitat completa de punta a punta al navegador. Però hi ha una cosa que continua sent mentida: en recarregar la pàgina, tot desapareix. El repositori en memòria va fer la seva feina —no bloquejar-te— i ara toca substituir-lo sense tocar ni una línia de vista, que és exactament per a això que vas definir el contracte. Això, més versionar el format desat i migrar-lo sense perdre dades, parlar amb una API de debò amb els seus estats i els seus errors, i treballar sense connexió amb una cua de canvis pendents, és Persistència i Sincronització de Dades.