Fins ara has vist la mateixa pantalla de Nómada Tasques escrita en JavaScript pur i en React, i les dues versions compartien un model: una funció que es torna a executar sencera i un motor que compara el resultat amb l'anterior. Vue canvia això d'arrel. La seva reactivitat és de gra fi: no compara arbres, sinó que registra quina expressió llegeix quina dada i actualitza només el que depèn del que ha canviat. És la família 2 de 10-01, en la seva versió més polida i accessible. I canvia també la unitat de treball: en lloc de repartir una targeta entre un <template>, un fitxer CSS i dos mòduls JavaScript, Vue l'agrupa sencera en un Component d'un Sol Fitxer, amb la seva plantilla, la seva lògica i els seus estils d'àmbit propi. En aquesta lliçó veuràs per què se'n diu framework progressiu i com s'afegeix tant a una pàgina existent com a un projecte complet; l'anatomia d'un component amb <template>, <script setup> i <style scoped>; tota la sintaxi de plantilla —interpolació, v-bind, v-on, v-if davant de v-show, v-for amb :key (el mateix data-id de sempre) i v-model explicat com a sucre i no com a màgia—; la reactivitat de debò, amb ref, reactive, per què existeix .value, com els proxies detecten les dependències i on es perd la reactivitat —l'error que més desconcerta—; computed comparat amb la teva memòria cau per versió de 09-02 i amb useMemo; watch i watchEffect amb el criteri per triar; el cicle de vida amb onMounted i onUnmounted, que torna a ser el teu destruir(); la comunicació amb props, emits, slots i provide/inject; els composables com a equivalent dels hooks personalitzats; Pinia en la seva versió mínima; i l'ecosistema oficial. Al final, la llista de tasques amb el seu filtre reimplementada en Vue i comparada amb les dues versions anteriors.

1. Què significa «framework progressiu»
2. Afegir Vue a una pàgina existent
3. Un projecte complet amb Vite
4. Components d'un Sol Fitxer
5. Per què agrupar plantilla, lògica i estils
6. La plantilla declarativa: interpolació
7. v-bind: atributs dinàmics
8. v-on: esdeveniments
9. v-if, v-else i v-show
10. v-for i :key
11. v-model: la doble vinculació explicada com a sucre
12. Reactivitat: ref i per què existeix .value
13. reactive i quan fer servir cadascun
14. Com detecten les dependències els proxies
15. Els límits de la reactivitat: on es perd
16. computed: derivats amb memòria cau
17. watch i watchEffect
18. Quan fer servir computed, watch o watchEffect
19. El cicle de vida: onMounted i onUnmounted
20. Comunicació: props i emits
21. slots: composició de contingut
22. provide i inject
23. Composables: usarTauler i usarFiltreResponsable
24. Estat global amb Pinia
25. L'ecosistema oficial i la fragmentació
26. Nómada Tasques en Vue: la llista completa
27. Comparació amb React i amb JavaScript pur
28. Errors Habituals i Consells
29. Exercicis
30. Conclusió

Vue es defineix a si mateix com un framework progressiu, i aquesta etiqueta té un significat tècnic concret: es pot adoptar per capes, començant per la més petita, sense comprometre's amb les altres.

Aquesta gradació no existeix a Angular, que exigeix tota la plataforma des del principi, i a React només existeix a mitges (necessites compilació per a JSX des del primer minut, tret que hi renunciïs). És la raó per la qual Vue apareix tant en projectes que van començar sense framework i van créixer: es poden convertir per trossos.

Per a Nómada Tasques això significa una cosa molt concreta. Podries agafar l'aplicació actual —el teu index.html, el teu Tauler, les teves utilitats— i convertir només la llista de tasques en un component Vue, deixant la resta intacta. No és un exercici teòric: és una estratègia de migració real, i la reprendràs a 10-06.

El nivell 1, sense cap eina:

Val la pena aturar-se aquí, perquè aquest bloc ja conté gairebé tots els conceptes de la lliçó i funciona obrint l'HTML al navegador, sense npm install, sense compilar i sense configurar res. Fixa't en tres coses:

• La plantilla és HTML vàlid. v-for, :value i {{ }} són atributs i text; el navegador els ignora fins que Vue els interpreta. Això té una conseqüència pràctica important: el marcatge es pot escriure en qualsevol editor d'HTML, i una persona de disseny l'entén.
• Vue només controla #tauler. La resta de la pàgina continua sent teva. Podries tenir tres illes Vue independents a la mateixa pàgina al costat del teu JavaScript de sempre.
• BACKLOG és el teu mòdul de dades, sense adaptar. Vue no té opinió sobre d'on surten els objectes.

Per a producció es faria servir una versió compilada en lloc de la que interpreta plantilles al navegador, però el model mental és aquest.

Per a la resta de la lliçó farem servir el nivell 2 en endavant:

L'assistent pregunta si vols TypeScript, Vue Router, Pinia, proves amb Vitest i Playwright o Cypress. Aquesta llista és reveladora: tot l'ecosistema essencial és oficial, mantingut pel mateix equip i amb documentació integrada. És el contrari de la taula de decisions de 10-02.

El punt d'entrada:

El fitxer .vue és la unitat de treball de Vue: plantilla, lògica i estils al mateix lloc.

Tres blocs, amb regles pròpies:

• <script setup> és sucre de compilació. Tot el que declaris al nivell superior —variables, funcions, importacions— queda disponible a la plantilla automàticament, sense return. És la forma actual i recomanada d'escriure components Vue; veuràs codi antic amb export default { setup() { … return { … } } } o amb data()/methods (l'API d'opcions), que continuen funcionant però ja no són la primera opció.
• <template> conté HTML amb directives. Es compila a una funció de renderitzat durant la construcció.
• <style scoped> aplica els estils només a aquest component. El compilador afegeix un atribut únic als elements del component i un altre als selectors, de manera que el .tasca d'aquí no pot afectar un .tasca d'un altre lloc.

Aquest scoped mereix un paràgraf propi, perquè és on Vue resol el problema 7 de 10-01 de manera més directa que React.

Recorda la teva targeta a Nómada Tasques: el <template id="plantilla-tasca"> a index.html, les classes .tasca__* a css/estils.css, la lògica a js/vista/targeta.js i el comportament a js/vista/controlador.js. Quatre fitxers, quatre acoblaments i cap comprovat. Canviar el nom de .tasca__titol al CSS no produeix cap error: simplement la targeta es veu malament.

Amb un fitxer .vue, els quatre són a la vista a la mateixa pantalla. Canviar el nom d'una classe és una operació de cercar i reemplaçar dins d'un fitxer de 40 línies. I com que els estils tenen àmbit, no cal inventar convencions de noms (BEM i similars) per evitar col·lisions: l'aïllament és real, no una disciplina.

L'objecció clàssica —«barrejar HTML, CSS i JavaScript és mala pràctica»— confon dues coses. La separació d'interessos no és separació de tecnologies: és separació de responsabilitats. L'estructura, l'aspecte i el comportament d'una targeta són un sol interès, i repartir-los per tres fitxers no els desacobla, només els allunya. És exactament l'argument de l'apartat 12 de 10-01 sobre el component com a unitat correcta de reutilització.

El text dinàmic s'escriu amb dobles claus:

A dins hi va una expressió JavaScript, no una sentència — la mateixa regla que les claus de JSX. I el contingut s'escapa sempre: és textContent, no innerHTML, amb la mateixa protecció de 06-02.

Diferència amb React que convé fixar: a JSX escrius {} per a tot el que és dinàmic, inclosos els atributs. A Vue, les claus són només per a text; els atributs fan servir v-bind.

Dos casos especials que es fan servir constantment:

Classes. :class accepta una cadena, un objecte (clau = classe, valor = condició) o un array, i es combina amb l'atribut class estàtic:

Compara-ho amb el que feies a pintarTargeta:

Quatre instruccions imperatives que cal mantenir sincronitzades —inclòs el remove previ, que és fàcil oblidar— davant d'una descripció declarativa. I davant de React, on cal construir la cadena a mà amb plantilles o una utilitat, la sintaxi d'objecte de Vue és notablement més neta.

Estils. :style accepta un objecte amb propietats en camelCase:

La diferència visible amb React és que a la plantilla pots escriure la crida directament (avancar(tasca.id)), sense embolcallar-la en una funció fletxa. El compilador se n'encarrega: @click="avancar(tasca.id)" es converteix en un gestor que executa aquesta expressió. Amb @click="avancar" (sense parèntesis) es passa la funció i rep l'esdeveniment com a argument.

Vue hi afegeix modificadors, que resolen de manera declarativa coses que en JavaScript pur escrius a mà:

Tots ells et resultaran familiars de 06-03 i 06-07. Són dreceres, no funcionalitat nova, però eliminen una classe sencera d'oblits — sobretot el preventDefault dels formularis.

Nota sobre delegació: com a React, escriure @click a cadascun de 600 elements no crea 600 escoltes del DOM. El compilador genera gestors i Vue els gestiona de manera eficient. El patró closest('[data-accio]') de 06-04 continua sent vàlid si el necessites, però ja no és obligatori.

I la comparació que cal tenir clara:

Aquesta taula és la formalització d'una cosa que ja vas mesurar a 09-04: amagar 594 tasques amb hidden mantenia 7.812 nodes al DOM, mentre que eliminar-les en deixava 1.194. v-if és el segon, v-show el primer. Per al filtre de responsable, v-if és el correcte.

Vue permet a més agrupar sense afegir cap node:

És l'equivalent del fragment <>…</> de React.

I aquí hi ha, per tercera vegada al mòdul, el mateix concepte: :key és el teu data-id de reconciliar (06-06) i la key de React (10-02). Vue el fa servir exactament igual: construeix un mapa de clau a node, aparella per clau i no per posició, reutilitza els que continuen vius i elimina els sobrants.

Les mateixes tres regles: estable, única entre germans, mai l'índex si la llista es mou. I un avantatge petit però útil de Vue: la regla d'ESLint del complement oficial marca com a error un v-for sense :key, mentre que a React només és un avís a la consola. És una decisió de framework «amb més opinions», en el sentit de 10-01.

Un detall que Vue fa millor que el DOM virtual pur: com que el compilador analitza la plantilla, sap quines parts són estàtiques i les salta per complet a les actualitzacions. Si el teu <li> té deu elements i només un depèn de dades, Vue n'actualitza un. React executa la funció sencera i compara els deu. És la barreja de famílies 2 i 3 de 10-01 en acció.

v-model és la característica més famosa de Vue i la pitjor entesa. Es presenta com a «doble vinculació» i sona a màgia bidireccional. No ho és: és sucre sintàctic de dues coses que ja saps fer.

es compila, essencialment, en:

És a dir: un v-bind que baixa el valor i un v-on que el puja. Exactament el formulari controlat de 10-02, escrit en una línia en lloc de dues. No hi ha canal màgic ni observació del DOM: hi ha un atribut i un esdeveniment.

Vue adapta la parella segons l'element, que és el que estalvia feina de debò:

Amb modificadors útils:

v-model.number mereix una nota, perquè connecta amb 01-07: sense això, <input type="number"> retorna una cadena, i hores > 40 compararia text. És un dels errors més freqüents en validar la R3.

En components propis, v-model funciona sobre una prop i un esdeveniment:

Un altre cop: una prop que baixa i un esdeveniment que puja. El flux de dades continua sent unidireccional; v-model només posa nom al patró. Entendre-ho així evita el malentès de creure que el fill modifica l'estat del pare — no ho fa: li demana que el modifiqui.

Arribem al cor de Vue.

La pregunta que tothom fa al principi: per què .value?

La resposta és en una limitació del llenguatge que coneixes des de 01-05: JavaScript no permet interceptar l'assignació a una variable. No hi ha manera que responsable = 'Iván' executi codi. Es pot interceptar l'accés a una propietat d'un objecte —això és el que fan els getter/setter de 05-03 i els Proxy—, però no a una variable solta.

Així que Vue fa l'única cosa possible: ref(null) retorna un objecte amb una única propietat, value, el get i el set de la qual estan interceptats.

Aquest .value que sembla una molèstia és, literalment, el preu que existeixi el mecanisme. I hi ha una compensació important: a la plantilla es desembolcalla sol. Dins de <template> escrius {{ responsable }}, no {{ responsable.value }}, perquè el compilador sap quines variables són refs i hi afegeix el .value per tu.

Comparació directa amb el que ja coneixes:

La tercera fila és la diferència fonamental. Canviar responsable.value no reexecuta App: reexecuta les expressions concretes que van llegir aquell ref. Aquest és el gra fi de 10-01.

I la quarta té una conseqüència pràctica molt útil: un ref es pot crear en un mòdul, exportar i modificar des de qualsevol lloc —inclòs el teu CanalTauler de 07-04 en rebre un missatge del WebSocket— sense estar dins de cap component.

reactive és l'alternativa per a objectes: embolcalla l'objecte sencer en un Proxy i no necessita .value.

És més còmode, però té quatre limitacions reals:

La recomanació actual, i la que segueix gairebé tot el codi Vue modern: fes servir ref per defecte. Funciona amb qualsevol tipus, es pot reemplaçar sencer, i el .value explícit fa visible on és la reactivitat. reactive queda per a objectes d'estat agrupat les propietats dels quals es manipulen una a una, i tot i així molts equips prefereixen un ref amb un objecte a dins:

Toca explicar el mecanisme de debò, perquè d'ell surten tots els comportaments —els bons i els estranys.

Vue manté, mentre executa un efecte reactiu (el render d'un component, un computed, un watchEffect), una referència a l'efecte actual. Quan durant aquella execució es llegeix una propietat reactiva, el Proxy intercepta la lectura i registra: «aquest efecte depèn d'aquesta propietat d'aquest objecte». Quan algú escriu aquella propietat, el proxy busca la llista d'efectes dependents i els torna a executar.

Tres conseqüències que expliquen tota la resta:

1 · La detecció és automàtica i precisa. No declares dependències com a l'array d'useEffect: es descobreixen en executar. Això elimina d'una revolada la classe sencera d'errors «falta una dependència» i «aquesta dependència canvia sempre» de 10-02.

2 · La detecció és dinàmica. Si un computed té un if, les dependències de la branca no presa no es registren en aquesta execució. És correcte i és el que vols: si el resultat no depèn d'una dada, canviar aquella dada no ha de recalcular res.

3 · La detecció només funciona durant l'execució de l'efecte. Si llegeixes un valor reactiu dins d'un setTimeout, un .then() o un addEventListener, aquella lectura passa després, quan l'efecte ja ha acabat i el registre està tancat. No es registra res. Aquesta és la causa de la meitat dels «això no s'actualitza» de Vue.

Aquest apartat és el que separa qui sap Vue de qui l'ha provat. La reactivitat es perd en quatre situacions, i totes tenen la mateixa causa: el vincle viu a la propietat, no al valor.

Límit 1 · Desestructurar un objecte reactiu.

toRefs recorre l'objecte i crea, per a cada propietat, un ref el get/set del qual apunten a la propietat original. És l'eina específica per desestructurar sense trencar res, i es fa servir molt en retornar l'estat des d'un composable.

Límit 2 · Desestructurar les props.

Amb un matís important: <script setup> té una transformació del compilador que fa reactiva la desestructuració de props escrita directament a defineProps. Fora d'aquest cas concret, la regla es manté.

Límit 3 · Passar un primitiu a una funció.

Aquest és el motiu profund pel qual ref és un objecte: els objectes es passen per referència i els primitius per valor, exactament com vas aprendre a 01-05 i 04-08. ref converteix un primitiu en una cosa que es pot passar sense perdre-la.

Límit 4 · Reemplaçar un objecte reactive sencer.

La comparació honesta amb React, que és la contrapartida anunciada a 10-01:

Cap dels dos no és «més fàcil». React t'obliga a declarar i per això ho pot comprovar amb una regla d'ESLint; Vue ho fa sol i per això la fallada és silenciosa. És un intercanvi real.

computed declara un valor derivat d'altres valors reactius:

Quatre propietats:

1. Es cacheja. El càlcul només s'executa si alguna dependència ha canviat. Llegir visibles.value cent vegades sense canvis executa el filtre una vegada.
2. Es compon. horesObertes depèn de visibles, que depèn de tasques i responsable. Vue construeix el graf i propaga en l'ordre correcte, sense recalcular res dues vegades.
3. És mandrós. Si ningú no llegeix horesObertes, no es calcula, encara que canviïn les tasques.
4. És de només lectura per defecte (se li pot definir un set, però és rar i gairebé sempre indica un disseny millorable).

I aquí hi ha el paral·lelisme que tanca 09-02:

Vas escriure vint línies —comptador de versió, invalidació a cada mutació, comparació de la clau de memòria cau— i el risc permanent d'oblidar un #invalidar(). computed fa el mateix, amb la invalidació descoberta automàticament i sense possibilitat d'oblit.

Comparació amb useMemo de React, que és l'equivalent més proper:

La tercera fila és la diferència cultural entre els dos frameworks. A React, useMemo és l'excepció i calcular directament és la norma. A Vue, computed és la norma: qualsevol derivat es declara així, sense pensar en rendiment, perquè és la manera correcta d'expressar-ho. I per això a Vue gairebé mai no es veu el debat sobre memoïtzació excessiva de 10-02.

Tots dos fan efectes secundaris quan alguna cosa canvia. Són l'equivalent d'useEffect, amb el mateix advertiment: no serveixen per derivar valors —per a això hi ha computed.

watch observa una font concreta i rep el valor nou i l'anterior:

watchEffect executa la funció immediatament i descobreix sol les seves dependències, com un computed però per a efectes:

I tots dos accepten una neteja, que és un altre cop el teu destruir():

Aquest bloc resol la condició de cursa de 10-02 amb el mateix AbortController de 07-03, i a Vue no cal declarar [responsable] en cap array: el watchEffect es va apuntar com a dependent en llegir responsable.value.

La taula que evita el 90 % dels errors de reactivitat a Vue:

Aquest últim cas mereix veure's escrit, perquè és exactament l'error de l'apartat 16 de 10-02 traduït a Vue:

Els mateixos tres defectes: dues fonts de veritat, un moment en què el valor està desfasat, i més codi. La regla és transferible entre frameworks: si és un valor, declara'l com a derivat; si és una acció, fes-la en un efecte.

Els moments principals, amb la seva equivalència:

La tercera fila torna a ser la important, i el missatge de 10-01 continua vigent: Vue et dona el moment garantit, no endevina què cal apagar. Un setInterval sense clearInterval a onUnmounted és exactament la mateixa fuita que en JavaScript pur.

Detall pràctic: un ref de plantilla (ref="contenidor" a l'HTML més const contenidor = ref(null) al script) és l'equivalent d'useRef de React i del teu $('.llista-tasques') de sempre. Val null fins que el component es munta, així que només es pot fer servir dins d'onMounted o després.

El flux és el mateix que a React —dades cap avall, esdeveniments cap amunt— amb una diferència: a Vue es declara explícitament en les dues direccions.

Diferències amb React que val la pena assenyalar:

La declaració d'emits és valuosa per una raó poc òbvia: documenta el contracte complet del component. Llegint defineProps i defineEmits saps tot el que entra i tot el que surt, sense cercar pel fitxer quines funcions es criden. A React aquesta informació està repartida per la signatura i cal reconstruir-la.

I la mateixa regla que a React: les props són de només lectura. Modificar props.tasca.estat des del fill és un error, i Vue avisa en desenvolupament. El fill emet; el pare decideix.

Els slots són l'equivalent de children de React, i són més expressius perquè admeten diversos forats amb nom.

I els slots amb àmbit, que permeten al fill passar dades al contingut que aporta el pare:

És un patró molt potent: el component aporta la lògica (el bucle, les claus, el filtratge) i qui el fa servir aporta la presentació. A React l'equivalent es fa passant una funció com a prop, i funciona igual de bé; la diferència és de sintaxi, no de capacitat.

L'equivalent de Context de React: posar un valor a disposició de tot el subarbre.

I una diferència tècnica amb Context que importa: com que Vue té reactivitat de gra fi, proveir un ref no repinta tots els que fan inject. Només s'actualitzen els que realment llegeixen el seu .value. El problema de rendiment de Context que descrivia 10-03 —tots els consumidors es repinten quan canvia el valor— senzillament no existeix aquí.

readonly és una bona pràctica: els descendents llegeixen el valor i per canviar-lo criden la funció proveïda. Així el control de l'estat es queda on ha de ser.

Un composable és una funció que fa servir l'API de reactivitat de Vue i retorna estat i operacions. És l'equivalent exacte dels hooks personalitzats de 10-02, amb una diferència important: no té regles d'ordre de crida, perquè Vue no identifica l'estat per posició sinó per objecte.

Compara avancar amb el seu equivalent de React a 10-02:

Aquesta és la diferència pràctica més visible entre els dos frameworks. A React la immutabilitat és obligatòria perquè la detecció és per referència; a Vue el proxy detecta l'escriptura a la propietat, així que mutar és correcte i natural. Cap de les dues no és millor: React guanya en previsibilitat —l'estat no canvia mai sota els teus peus i les comparacions són trivials— i Vue guanya en concisió i en el fet que les 599 tasques que no canvien ni tan sols es toquen.

Una convenció sobre noms: l'ecosistema Vue fa servir useAlgunaCosa en anglès, igual que React. Aquí s'escriuen usarTauler i usarFiltreResponsable per coherència amb la resta del curs, però en codi real veuràs useTauler. El que importa és que sigui consistent.

Pinia és el magatzem oficial de Vue, i la seva versió mínima s'assembla sorprenentment a un composable:

storeToRefs és imprescindible i és una aplicació directa del límit 1 de l'apartat 15: desestructurar el magatzem copiaria els valors i trencaria la reactivitat. storeToRefs converteix l'estat i els derivats en refs vinculats; les accions són funcions normals i es poden desestructurar sense problema.

Comparat amb Redux (10-03):

La conclusió de 10-03 es manté: comença sense magatzem. Un composable amb un ref en un mòdul ja és estat compartit —perquè un ref de mòdul és un objecte únic—, i sovint n'hi ha prou. Pinia hi afegeix DevTools, substitució en calent, la garantia d'una única instància i suport per a renderitzat al servidor. La diferència amb Redux és que l'esglaó és molt més baix: passar d'un composable a un magatzem Pinia són deu minuts.

Aquesta columna de l'esquerra explica per què es diu que Vue té menys fragmentació, i mereix una anàlisi honesta en les dues direccions.

Avantatges reals: hi ha una resposta canònica a cada pregunta; la documentació oficial cobreix el conjunt i els exemples encaixen entre si; les actualitzacions estan coordinades; dos projectes Vue d'empreses diferents s'assemblen força, amb la qual cosa incorporar-se a un és més ràpid; i no cal dedicar una setmana a avaluar quatre llibreries d'encaminament.

Desavantatges reals: menys innovació des de fora, perquè hi ha menys incentiu per competir amb la solució oficial; menys opcions quan el teu cas és rar; i un ecosistema de tercers més petit en números absoluts —per a una necessitat molt específica és més probable trobar una llibreria React que una de Vue—.

És l'eix llibreria-framework de 10-01 amb Vue situat al mig: més opinions que React, menys que Angular. I també aquí convé desconfiar de les conclusions automàtiques: la fragmentació de React és un cost per a un equip petit i un avantatge per a un que necessita alguna cosa poc comuna.

La pantalla objectiu del mòdul, tercera versió. El domini és el mateix fitxer JavaScript de 10-02 i 10-03, sense tocar:

El filtre:

La targeta és la de l'apartat 4. I la llista:

I l'aplicació:

Els números canònics, verificats: sense filtre, «6 de 6 tasques · 45 h obertes». Amb «Iván», «3 de 6 · 25 h». Amb «Lucía», «1 de 6 · 14 h». Amb «Marta», «2 de 6 · 6 h». I en prémer «Començar» a la tasca 6, avancar muta tasca.estat, el proxy avisa els computed que van llegir aquella propietat, i s'actualitzen només la targeta afectada i el resum. Les altres cinc targetes ni tan sols es tornen a executar.

La taula de les tres versions de la mateixa pantalla:

I les mètriques de la mateixa pantalla:

I el balanç qualitatiu, sense declarar guanyadors:

Vue guanya en: concisió (menys cerimònia per al mateix), estils aïllats sense convencions de noms, reactivitat automàtica que elimina l'array de dependències, computed com a forma natural en lloc d'optimització, un ecosistema oficial coherent i una corba d'aprenentatge més suau per a qui ve d'HTML i CSS.

React guanya en: mida del mercat laboral i de l'ecosistema de tercers, un model mental més simple d'explicar (és una funció que es reexecuta), «tot és JavaScript» sense sintaxi de plantilla per aprendre, millor suport d'eines de tercers, i React Native per a mòbil natiu.

JavaScript pur guanya en: zero dependències, zero pes de motor, zero compilació obligatòria, control absolut i un codi que continuarà funcionant d'aquí a deu anys sense actualitzar res.

Les contrapartides de Vue, dites amb claredat: la reactivitat automàtica falla en silenci quan es perd (apartat 15), i la fallada és «no s'actualitza», que és més difícil de diagnosticar que un error; la sintaxi de plantilla és un llenguatge addicional que cal aprendre i que les eines genèriques no entenen sense complements; i el mercat laboral és més petit que el de React a la majoria de llocs, cosa que és un criteri legítim encara que no sigui tècnic.

Oblidar .value al script. L'error número u. A la plantilla es desembolcalla sol, al script no. if (responsable === 'Iván') compara un objecte ref amb una cadena i sempre és fals, sense error. La regla d'ESLint del complement oficial de Vue ho detecta: activa-la.

Desestructurar un objecte reactiu o un magatzem de Pinia. const { responsable } = filtres copia el valor i trenca el vincle. Fes servir toRefs per a objectes reactius i storeToRefs per a magatzems.

Llegir valors reactius fora del context de seguiment. Dins d'un setTimeout, un .then() o un gestor registrat a mà, la lectura no es registra. Llegeix el valor abans, al cos de l'efecte.

Fer servir watch per derivar valors. És el mateix antipatró que useEffect per derivar estat a React: dues fonts de veritat i un instant de desfasament. Si és un valor, és computed.

Confondre v-if amb v-show. v-show deixa els nodes al DOM: amb 600 tasques, 600 nodes amagats, trobables amb Ctrl+F, amb el cost de memòria i d'arbre d'accessibilitat que vas mesurar a 09-04. Per filtrar, v-if.

Fer servir l'índex com a :key. El mateix error que a React i que al teu reconciliar. Si la llista es filtra o es reordena, els nodes canvien de dada i es perden el focus i l'estat intern.

Oblidar .prevent als formularis. @submit sense .prevent recarrega la pàgina. És tan freqüent que Vue va fer el modificador precisament per això.

Oblidar .number als camps numèrics. <input type="number" v-model="hores"> guarda una cadena. La validació de la R3 (hores > 0 && hores <= 40) compararia text. Fes servir v-model.number.

Mutar props des del fill. Vue avisa en desenvolupament. El fill emet un esdeveniment; el pare decideix què fer. És el flux unidireccional, que v-model no trenca sinó que formalitza.

Creure que v-model és màgia bidireccional. És un v-bind més un v-on. Entendre-ho així evita esperar comportaments que no existeixen.

Consell: fes servir ref per defecte i reactive només quan ho justifiquis. ref funciona amb qualsevol tipus, es pot reemplaçar sencer, i el .value fa visible on és la reactivitat.

Consell: mantén el domini fora dels components. domini/regles.js és el mateix fitxer a les tres versions d'aquesta pantalla, i aquesta és la millor prova que la disciplina de 10-01 funciona: en canviar de framework només es reescriu la vista.

Consell: instal·la Vue DevTools des del primer dia. Permet inspeccionar l'arbre de components, veure el valor de cada ref i cada computed en temps real, i —molt útil— veure quines dependències té registrades cada efecte, que és la manera directa de diagnosticar una reactivitat perduda.

Aquest component té quatre fallades de reactivitat. Troba-les, explica per què falla cadascuna i escriu la versió corregida.

Escriu un composable usarTasquesRemotes(responsable) que:

1. Rebi un ref amb el responsable filtrat.
2. Carregui les tasques del servidor amb el teu llistarTasques de 07-02 cada vegada que canviï el responsable.
3. Exposi tasques, carregant i error com a refs.
4. Cancel·li la petició anterior en llançar-ne una de nova i en desmuntar el component, evitant la condició de cursa de 10-02.
5. Exposi també un computed amb les hores obertes de les tasques carregades.

Després, explica per què aquesta versió no necessita cap array de dependències i quin error de React s'evita amb això.

Sense escriure codi nou, omple aquesta taula comparant el mateix canvi funcional a les tres versions de la pantalla que has vist al mòdul: afegir un distintiu que mostri l'esforç ponderat de cada tasca (horesEstimades × PESOS[prioritat]), amb fons vermell si supera 30.

Després respon: a la versió de JavaScript pur, què passaria si afegissis el distintiu a pintarTargeta però oblidessis afegir-lo també al <template> d'index.html?

Solució 1

Fallada 1 · const { responsable } = filtres (línia 6). Desestructurar un objecte reactive copia el valor primitiu null i perd el vincle. responsable valdrà null per sempre, així que visibles no filtrarà mai res encara que l'usuari canviï el <select>. És el límit 1 de l'apartat 15.

Fallada 2 · watch per derivar horesObertes. És l'antipatró de l'apartat 18: dues fonts de veritat, un instant de desfasament i més codi. A més, com que tasques és un ref a un array i el watch no és profund, mutar l'estat d'una tasca no dispara el watch: horesObertes es quedaria obsoleta en marcar una tasca com a feta, que és justament el cas d'ús principal.

Fallada 3 · Lectura dins d'un setTimeout al computed. La lectura de filtres.text passa després que el computed hagi acabat, fora del context de seguiment: no es registra com a dependència. A més, un computed no ha de tenir efectes secundaris: ha de ser una funció pura de les seves dependències, igual que els teus reductors de 10-03.

Fallada 4 · filtres = { … } a netejar. Reassignar un objecte reactive trenca el vincle amb la plantilla, que continua apuntant al proxy original. A més, filtres està declarat amb const, així que això llançaria un TypeError en temps d'execució (01-05).

Versió corregida:

Nota sobre la desestructuració de la línia const { responsable, text } = filtres.value: aquí sí que és correcta, perquè passa dins del computed. La lectura de filtres.value registra la dependència en aquell moment; el que es desestructura després són valors ja llegits, usats immediatament. La regla no és «no desestructuris mai», sinó «no guardis valors desestructurats fora d'un context reactiu».

Solució 2

Ús:

Per què no cal array de dependències. El watchEffect llegeix responsable.value durant la seva execució, i el proxy registra aquella lectura automàticament. Quan el valor canvia, l'efecte es torna a executar — després d'haver cridat la neteja, que avorta la petició en vol.

Quin error de React s'evita. Dos, en realitat:

1. La dependència oblidada. A React, escriure }, []) en lloc de }, [responsable]) produeix un component que carrega una vegada i no s'actualitza mai. És tan freqüent que existeix una regla d'ESLint específica per a això. Aquí és impossible per construcció.
2. La dependència que canvia sempre. Si a React passessis un objecte { responsable } com a dependència, es recrearia a cada renderitzat i la petició es llançaria infinitament. A Vue les dependències són els valors reactius llegits, no referències comparades.

I un avís, per no vendre fum: hi ha un cas on el seguiment automàtic de Vue també falla. Les lectures que passen després d'un await no es registren, perquè el context de seguiment es tanca en suspendre's la funció. Per això el codi llegeix responsable.value abans de l'await, dins de la crida. Si necessitessis llegir un altre ref després de l'await, l'hauries de llegir abans i guardar-lo. És el mateix límit de l'apartat 15, en la seva forma més subtil.

Solució 3

Què passa si oblides el <span> al <template> d'index.html. Depèn de com estigui escrit pintarTargeta. Si fa servir $('.tasca__esforc', li).textContent = …, el selector retorna null i la línia llança un TypeError: Cannot set properties of null en temps d'execució, en pintar la primera targeta: l'aplicació es trenca sencera. Si en canvi ho comprova abans (const distintiu = $('.tasca__esforc', li); if (distintiu) …), no passa res visible: el distintiu simplement no apareix, sense cap error, i la fallada només es detecta mirant la pantalla o amb una prova d'extrem a extrem (08-06).

Aquest és, amb nom i cognoms, l'acoblament sense comprovar del qual parlava l'apartat 13 de 10-01. A la versió Vue l'error és impossible: el marcatge i el codi que l'omple són el mateix fitxer, i el compilador de plantilles avisa si una variable no existeix.

Has vist Vue en la seva versió moderna —Composition API i <script setup>— i, sobretot, has vist el segon model de reactivitat de 10-01 funcionant de debò.

Saps què significa framework progressiu i ho has comprovat: els mateixos conceptes serveixen per millorar una pàgina existent amb una etiqueta <script> i sense compilar, o per muntar una aplicació completa amb Vite, Vue Router i Pinia. Coneixes els Components d'un Sol Fitxer amb els seus tres blocs i per què agrupar plantilla, lògica i estils no viola la separació d'interessos sinó que la respecta: l'estructura, l'aspecte i el comportament d'una targeta són un sol interès, i el <style scoped> converteix l'aïllament en una garantia del compilador en lloc d'una convenció de noms.

Domines la sintaxi de plantilla: la interpolació amb el seu escapament automàtic, v-bind amb les formes d'objecte per a classes i estils —quatre instruccions imperatives de classList reduïdes a una descripció—, v-on amb els seus modificadors que codifiquen el preventDefault i el stopPropagation de 06-03, la diferència entre v-if i v-show —crear i destruir davant de display: none, amb els 7.812 nodes davant dels 1.194 que vas mesurar a 09-04—, v-for amb :key, que per tercera vegada al mòdul és el teu data-id de 06-06, i v-model desmitificat: un v-bind que baixa el valor i un v-on que el puja, el formulari controlat de 10-02 escrit en una línia, amb .trim i .number que eviten errors reals a les regles R2 i R3.

Entens la reactivitat per dins. Saps per què existeix .value —JavaScript no permet interceptar l'assignació a una variable, només a una propietat— i que un ref és un objecte amb get/set interceptats, exactament el mecanisme de 05-03. Saps com els proxies registren les dependències durant l'execució d'un efecte, amb les seves tres conseqüències: detecció automàtica i precisa, detecció dinàmica que ignora les branques no preses, i detecció només durant l'execució — d'on surten els quatre límits on la reactivitat es perd: desestructurar un objecte reactiu, desestructurar props, passar un primitiu a una funció i reemplaçar un reactive sencer, amb toRefs i storeToRefs com a eines. I tens la comparació honesta: React t'obliga a declarar dependències i per això les pot comprovar amb ESLint; Vue les descobreix sola i per això la fallada és silenciosa.

Saps que computed és la teva memòria cau per versió de 09-02 amb la invalidació descoberta automàticament —vint línies i un risc d'oblit convertits en una línia sense risc—, i que a diferència d'useMemo no és una optimització sinó la forma natural d'escriure derivats. Distingeixes watch i watchEffect amb el criteri per triar entre els tres, i reconeixes l'antipatró de derivar amb watch com el mateix error que derivar amb useEffect. Coneixes el cicle de vida amb onMounted i onUnmounted, que torna a ser el teu destruir() amb la crida garantida però el contingut a càrrec teu.

Saps comunicar components amb props i emits declarats —un contracte complet i validat que es llegeix en dues línies—, compondre contingut amb slots amb nom i amb àmbit, i injectar valors amb provide/inject, que a diferència de Context no repinta tots els consumidors perquè la reactivitat és de gra fi. Extreus lògica en composables sense regles d'ordre de crida, i saps que la diferència pràctica més visible amb React és a avancar: on React exigeix un map immutable, Vue muta la propietat i el proxy fa la resta. Coneixes Pinia en la seva versió mínima —gairebé idèntica a un composable, amb storeToRefs com a requisit— i l'ecosistema oficial que explica la menor fragmentació de Vue, amb els seus avantatges i els seus costos.

I has vist la tercera versió de la mateixa pantalla, amb el mateix domini/regles.js sense tocar a les tres, ~120 línies, un sol fitxer per component amb els seus estils aïllats, i actualitzacions que toquen només el que ha canviat. Amb les contrapartides dites: la reactivitat perduda falla en silenci, la sintaxi de plantilla és un llenguatge més, i el mercat laboral és més petit.

Queden dos models per veure. El següent és el més diferent de tots: un framework que no és una llibreria ni un framework progressiu sinó una plataforma completa, amb TypeScript com a requisit de fet, injecció de dependències, una CLI que ho genera tot, observables per als fluxos asíncrons, i —des de fa poc— senyals molt semblants als ref que acabes d'aprendre. És l'extrem «amb opinions» de l'eix de 10-01: Conceptes Bàsics d'Angular.