Hasta ahora has visto la misma pantalla de Nómada Tareas escrita en JavaScript puro y en React, y las dos versiones compartían un modelo: una función que se vuelve a ejecutar entera y un motor que compara el resultado con el anterior. Vue cambia eso de raíz. Su reactividad es de grano fino: no compara árboles, sino que registra qué expresión lee qué dato y actualiza solo lo que depende de lo que ha cambiado. Es la familia 2 de 10-01, en su versión más pulida y accesible. Y cambia también la unidad de trabajo: en lugar de repartir una tarjeta entre un <template>, un fichero CSS y dos módulos JavaScript, Vue la agrupa entera en un Componente de un Solo Fichero, con su plantilla, su lógica y sus estilos con ámbito propio. En esta lección verás por qué se le llama framework progresivo y cómo se añade tanto a una página existente como a un proyecto completo; la anatomía de un componente con <template>, <script setup> y <style scoped>; toda la sintaxis de plantilla —interpolación, v-bind, v-on, v-if frente a v-show, v-for con :key (el mismo data-id de siempre) y v-model explicado como azúcar y no como magia—; la reactividad de verdad, con ref, reactive, por qué existe .value, cómo los proxies detectan las dependencias y dónde se pierde la reactividad —el error que más desconcierta—; computed comparado con tu caché por versión de 09-02 y con useMemo; watch y watchEffect con el criterio para elegir; el ciclo de vida con onMounted y onUnmounted, que vuelve a ser tu destruir(); la comunicación con props, emits, slots y provide/inject; los composables como equivalente de los hooks personalizados; Pinia en su versión mínima; y el ecosistema oficial. Al final, la lista de tareas con su filtro reimplementada en Vue y comparada con las dos versiones anteriores.

1. Qué significa «framework progresivo»
2. Añadir Vue a una página existente
3. Un proyecto completo con Vite
4. Componentes de un Solo Fichero
5. Por qué agrupar plantilla, lógica y estilos
6. La plantilla declarativa: interpolación
7. v-bind: atributos dinámicos
8. v-on: eventos
9. v-if, v-else y v-show
10. v-for y :key
11. v-model: la doble vinculación explicada como azúcar
12. Reactividad: ref y por qué existe .value
13. reactive y cuándo usar cada uno
14. Cómo detectan las dependencias los proxies
15. Los límites de la reactividad: dónde se pierde
16. computed: derivados con caché
17. watch y watchEffect
18. Cuándo usar computed, watch o watchEffect
19. El ciclo de vida: onMounted y onUnmounted
20. Comunicación: props y emits
21. slots: composición de contenido
22. provide e inject
23. Composables: usarTablero y usarFiltroResponsable
24. Estado global con Pinia
25. El ecosistema oficial y la fragmentación
26. Nómada Tareas en Vue: la lista completa
27. Comparación con React y con JavaScript puro
28. Errores Comunes y Consejos
29. Ejercicios
30. Conclusión

Vue se define a sí mismo como un framework progresivo, y esa etiqueta tiene un significado técnico concreto: se puede adoptar por capas, empezando por la más pequeña, sin comprometerse con las demás.

Esa gradación no existe en Angular, que exige toda la plataforma desde el principio, y en React solo existe a medias (necesitas compilación para JSX desde el primer minuto, salvo que renuncies a él). Es la razón por la que Vue aparece tanto en proyectos que empezaron sin framework y crecieron: se pueden convertir por trozos.

Para Nómada Tareas eso significa algo muy concreto. Podrías coger la aplicación actual —tu index.html, tu Tablero, tus utilidades— y convertir solo la lista de tareas en un componente Vue, dejando el resto intacto. No es un ejercicio teórico: es una estrategia de migración real, y la retomarás en 10-06.

El nivel 1, sin ninguna herramienta:

Merece la pena detenerse aquí, porque este bloque ya contiene casi todos los conceptos de la lección y funciona abriendo el HTML en el navegador, sin npm install, sin compilar y sin configurar nada. Fíjate en tres cosas:

• La plantilla es HTML válido. v-for, :value y {{ }} son atributos y texto; el navegador los ignora hasta que Vue los interpreta. Esto tiene una consecuencia práctica importante: el marcado se puede escribir en cualquier editor de HTML, y una persona de diseño lo entiende.
• Vue solo controla #tablero. El resto de la página sigue siendo tuyo. Podrías tener tres islas Vue independientes en la misma página junto a tu JavaScript de siempre.
• BACKLOG es tu módulo de datos, sin adaptar. Vue no tiene opinión sobre de dónde salen los objetos.

Para producción se usaría una versión compilada en lugar de la que interpreta plantillas en el navegador, pero el modelo mental es este.

Para el resto de la lección usaremos el nivel 2 en adelante:

El asistente pregunta si quieres TypeScript, Vue Router, Pinia, pruebas con Vitest y Playwright o Cypress. Esa lista es reveladora: todo el ecosistema esencial es oficial, mantenido por el mismo equipo y con documentación integrada. Es lo contrario de la tabla de decisiones de 10-02.

El punto de entrada:

El fichero .vue es la unidad de trabajo de Vue: plantilla, lógica y estilos en el mismo sitio.

Tres bloques, con reglas propias:

• <script setup> es azúcar de compilación. Todo lo que declares en el nivel superior —variables, funciones, importaciones— queda disponible en la plantilla automáticamente, sin return. Es la forma actual y recomendada de escribir componentes Vue; verás código antiguo con export default { setup() { … return { … } } } o con data()/methods (la API de opciones), que siguen funcionando pero ya no son la primera opción.
• <template> contiene HTML con directivas. Se compila a una función de renderizado durante la construcción.
• <style scoped> aplica los estilos solo a este componente. El compilador añade un atributo único a los elementos del componente y otro a los selectores, de modo que .tarea de aquí no puede afectar a un .tarea de otro sitio.

Ese scoped merece un párrafo propio, porque es donde Vue resuelve el problema 7 de 10-01 de forma más directa que React.

Recuerda tu tarjeta en Nómada Tareas: el <template id="plantilla-tarea"> en index.html, las clases .tarea__* en css/estilos.css, la lógica en js/vista/tarjeta.js y el comportamiento en js/vista/controlador.js. Cuatro ficheros, cuatro acoplamientos y ninguno comprobado. Renombrar .tarea__titulo en el CSS no produce ningún error: simplemente la tarjeta se ve mal.

Con un fichero .vue, los cuatro están a la vista en la misma pantalla. Cambiar el nombre de una clase es una operación de buscar y reemplazar dentro de un fichero de 40 líneas. Y como los estilos tienen ámbito, no hay que inventar convenciones de nombres (BEM y similares) para evitar colisiones: el aislamiento es real, no una disciplina.

La objeción clásica —«mezclar HTML, CSS y JavaScript es mala práctica»— confunde dos cosas. La separación de intereses no es separación de tecnologías: es separación de responsabilidades. La estructura, el aspecto y el comportamiento de una tarjeta son un solo interés, y repartirlos por tres ficheros no los desacopla, solo los aleja. Es exactamente el argumento del apartado 12 de 10-01 sobre el componente como unidad correcta de reutilización.

El texto dinámico se escribe con dobles llaves:

Dentro va una expresión JavaScript, no una sentencia — la misma regla que las llaves de JSX. Y el contenido se escapa siempre: es textContent, no innerHTML, con la misma protección de 06-02.

Diferencia con React que conviene fijar: en JSX escribes {} para todo lo dinámico, incluidos los atributos. En Vue, las llaves son solo para texto; los atributos usan v-bind.

Dos casos especiales que se usan constantemente:

Clases. :class acepta una cadena, un objeto (clave = clase, valor = condición) o un array, y se combina con el atributo class estático:

Compara con lo que hacías en pintarTarjeta:

Cuatro instrucciones imperativas que hay que mantener sincronizadas —incluido el remove previo, que es fácil olvidar— frente a una descripción declarativa. Y frente a React, donde hay que construir la cadena a mano con plantillas o una utilidad, la sintaxis de objeto de Vue es notablemente más limpia.

Estilos. :style acepta un objeto con propiedades en camelCase:

La diferencia visible con React es que en la plantilla puedes escribir la llamada directamente (avanzar(tarea.id)), sin envolverla en una función flecha. El compilador se encarga: @click="avanzar(tarea.id)" se convierte en un manejador que ejecuta esa expresión. Con @click="avanzar" (sin paréntesis) se pasa la función y recibe el evento como argumento.

Vue añade modificadores, que resuelven de forma declarativa cosas que en JavaScript puro escribes a mano:

Todos ellos te resultarán familiares de 06-03 y 06-07. Son atajos, no funcionalidad nueva, pero eliminan una clase entera de olvidos — sobre todo el preventDefault de los formularios.

Nota sobre delegación: como en React, escribir @click en cada uno de 600 elementos no crea 600 escuchas del DOM. El compilador genera manejadores y Vue los gestiona de forma eficiente. El patrón closest('[data-accion]') de 06-04 sigue siendo válido si lo necesitas, pero ya no es obligatorio.

Y la comparación que hay que tener clara:

Esta tabla es la formalización de algo que ya mediste en 09-04: ocultar 594 tareas con hidden mantenía 7.812 nodos en el DOM, mientras que eliminarlas dejaba 1.194. v-if es lo segundo, v-show lo primero. Para el filtro de responsable, v-if es lo correcto.

Vue permite además agrupar sin añadir un nodo:

Es el equivalente del fragmento <>…</> de React.

Y aquí está, por tercera vez en el módulo, el mismo concepto: :key es tu data-id de reconciliar (06-06) y la key de React (10-02). Vue lo usa exactamente igual: construye un mapa de clave a nodo, empareja por clave y no por posición, reutiliza los que siguen vivos y elimina los sobrantes.

Las mismas tres reglas: estable, única entre hermanos, nunca el índice si la lista se mueve. Y una ventaja pequeña pero útil de Vue: la regla de ESLint del complemento oficial marca como error un v-for sin :key, mientras que en React es solo un aviso en la consola. Es una decisión de framework «con más opiniones», en el sentido de 10-01.

Un detalle que Vue hace mejor que el DOM virtual puro: como el compilador analiza la plantilla, sabe qué partes son estáticas y las salta por completo en las actualizaciones. Si tu <li> tiene diez elementos y solo uno depende de datos, Vue actualiza uno. React ejecuta la función entera y compara los diez. Es la mezcla de familias 2 y 3 de 10-01 en acción.

v-model es la característica más famosa de Vue y la peor entendida. Se presenta como «doble vinculación» y suena a magia bidireccional. No lo es: es azúcar sintáctico de dos cosas que ya sabes hacer.

se compila, esencialmente, en:

Es decir: un v-bind que baja el valor y un v-on que lo sube. Exactamente el formulario controlado de 10-02, escrito en una línea en lugar de dos. No hay canal mágico ni observación del DOM: hay un atributo y un evento.

Vue adapta la pareja según el elemento, que es lo que ahorra trabajo de verdad:

Con modificadores útiles:

v-model.number merece una nota, porque conecta con 01-07: sin él, <input type="number"> devuelve una cadena, y horas > 40 compararía texto. Es uno de los errores más frecuentes al validar la R3.

En componentes propios, v-model funciona sobre una prop y un evento:

Otra vez: una prop que baja y un evento que sube. El flujo de datos sigue siendo unidireccional; v-model solo pone nombre al patrón. Entenderlo así evita el malentendido de creer que el hijo modifica el estado del padre — no lo hace: le pide que lo modifique.

Llegamos al corazón de Vue.

La pregunta que todo el mundo hace al principio: ¿por qué .value?

La respuesta está en una limitación del lenguaje que conoces desde 01-05: JavaScript no permite interceptar la asignación a una variable. No hay forma de que responsable = 'Iván' ejecute código. Se puede interceptar el acceso a una propiedad de un objeto —eso es lo que hacen los getter/setter de 05-03 y los Proxy—, pero no a una variable suelta.

Así que Vue hace lo único posible: ref(null) devuelve un objeto con una única propiedad, value, cuyo get y set están interceptados.

Ese .value que parece una molestia es, literalmente, el precio de que exista el mecanismo. Y hay una compensación importante: en la plantilla se desenvuelve solo. Dentro de <template> escribes {{ responsable }}, no {{ responsable.value }}, porque el compilador sabe qué variables son refs y añade el .value por ti.

Comparación directa con lo que ya conoces:

La tercera fila es la diferencia fundamental. Cambiar responsable.value no reejecuta App: reejecuta las expresiones concretas que leyeron ese ref. Ese es el grano fino de 10-01.

Y la cuarta tiene una consecuencia práctica muy útil: un ref se puede crear en un módulo, exportar y modificar desde cualquier sitio —incluido tu CanalTablero de 07-04 al recibir un mensaje del WebSocket— sin estar dentro de ningún componente.

reactive es la alternativa para objetos: envuelve el objeto entero en un Proxy y no necesita .value.

Es más cómodo, pero tiene cuatro limitaciones reales:

La recomendación actual, y la que sigue casi todo el código Vue moderno: usa ref por defecto. Funciona con cualquier tipo, se puede reemplazar entero, y el .value explícito hace visible dónde está la reactividad. reactive queda para objetos de estado agrupado cuyas propiedades se manipulan una a una, y aun así muchos equipos prefieren un ref con un objeto dentro:

Toca explicar el mecanismo de verdad, porque de él salen todos los comportamientos —los buenos y los raros.

Vue mantiene, mientras ejecuta un efecto reactivo (el render de un componente, un computed, un watchEffect), una referencia al efecto actual. Cuando durante esa ejecución se lee una propiedad reactiva, el Proxy intercepta la lectura y registra: «este efecto depende de esta propiedad de este objeto». Cuando alguien escribe esa propiedad, el proxy busca la lista de efectos dependientes y los vuelve a ejecutar.

Tres consecuencias que explican todo lo demás:

1 · La detección es automática y precisa. No declaras dependencias como en el array de useEffect: se descubren al ejecutar. Eso elimina de un plumazo la clase entera de errores «falta una dependencia» y «esta dependencia cambia siempre» de 10-02.

2 · La detección es dinámica. Si un computed tiene un if, las dependencias de la rama no tomada no se registran en esta ejecución. Es correcto y es lo que quieres: si el resultado no depende de un dato, cambiar ese dato no debe recalcular nada.

3 · La detección solo funciona durante la ejecución del efecto. Si lees un valor reactivo dentro de un setTimeout, un .then() o un addEventListener, esa lectura ocurre después, cuando el efecto ya terminó y el registro está cerrado. No se registra nada. Esta es la causa de la mitad de los «esto no se actualiza» de Vue.

Este apartado es el que separa a quien sabe Vue de quien lo ha probado. La reactividad se pierde en cuatro situaciones, y todas tienen la misma causa: el vínculo vive en la propiedad, no en el valor.

Límite 1 · Desestructurar un objeto reactivo.

toRefs recorre el objeto y crea, para cada propiedad, un ref cuyo get/set apuntan a la propiedad original. Es la herramienta específica para desestructurar sin romper nada, y se usa mucho al devolver el estado desde un composable.

Límite 2 · Desestructurar las props.

Con un matiz importante: <script setup> tiene una transformación del compilador que hace reactiva la desestructuración de props escrita directamente en defineProps. Fuera de ese caso concreto, la regla se mantiene.

Límite 3 · Pasar un primitivo a una función.

Este es el motivo profundo por el que ref es un objeto: los objetos se pasan por referencia y los primitivos por valor, exactamente como aprendiste en 01-05 y 04-08. ref convierte un primitivo en algo que se puede pasar sin perderlo.

Límite 4 · Reemplazar un objeto reactive entero.

La comparación honesta con React, que es la contrapartida anunciada en 10-01:

Ninguno de los dos es «más fácil». React te obliga a declarar y por eso puede comprobarlo con una regla de ESLint; Vue lo hace solo y por eso el fallo es silencioso. Es un intercambio real.

computed declara un valor derivado de otros valores reactivos:

Cuatro propiedades:

1. Se cachea. El cálculo solo se ejecuta si alguna dependencia cambió. Leer visibles.value cien veces sin cambios ejecuta el filtro una vez.
2. Se compone. horasAbiertas depende de visibles, que depende de tareas y responsable. Vue construye el grafo y propaga en el orden correcto, sin recalcular nada dos veces.
3. Es perezoso. Si nadie lee horasAbiertas, no se calcula, aunque cambie tareas.
4. Es de solo lectura por defecto (se puede definir un set, pero es raro y casi siempre indica un diseño mejorable).

Y aquí está el paralelismo que cierra 09-02:

Escribiste veinte líneas —contador de versión, invalidación en cada mutación, comparación de la clave de caché— y el riesgo permanente de olvidar un #invalidar(). computed hace lo mismo, con la invalidación descubierta automáticamente y sin posibilidad de olvido.

Comparación con useMemo de React, que es el equivalente más cercano:

La tercera fila es la diferencia cultural entre los dos frameworks. En React, useMemo es la excepción y calcular directamente es la norma. En Vue, computed es la norma: cualquier derivado se declara así, sin pensar en rendimiento, porque es la forma correcta de expresarlo. Y por eso en Vue casi nunca se ve el debate sobre memoización excesiva de 10-02.

Los dos hacen efectos secundarios cuando algo cambia. Son el equivalente de useEffect, con la misma advertencia: no son para derivar valores —para eso está computed.

watch observa una fuente concreta y recibe el valor nuevo y el anterior:

watchEffect ejecuta la función inmediatamente y descubre solas sus dependencias, como un computed pero para efectos:

Y ambos aceptan una limpieza, que es otra vez tu destruir():

Ese bloque resuelve la condición de carrera de 10-02 con el mismo AbortController de 07-03, y en Vue no hay que declarar [responsable] en ningún array: el watchEffect se apuntó como dependiente al leer responsable.value.

La tabla que evita el 90 % de los errores de reactividad en Vue:

Ese último caso merece verse escrito, porque es exactamente el error del apartado 16 de 10-02 traducido a Vue:

Los mismos tres defectos: dos fuentes de verdad, un momento en que el valor está desfasado, y más código. La regla es transferible entre frameworks: si es un valor, decláralo como derivado; si es una acción, hazla en un efecto.

Los momentos principales, con su equivalencia:

La tercera fila vuelve a ser la importante, y el mensaje de 10-01 sigue vigente: Vue te da el momento garantizado, no adivina qué apagar. Un setInterval sin clearInterval en onUnmounted es exactamente la misma fuga que en JavaScript puro.

Detalle práctico: un ref de plantilla (ref="contenedor" en el HTML más const contenedor = ref(null) en el script) es el equivalente de useRef de React y de tu $('.lista-tareas') de siempre. Vale null hasta que el componente se monta, así que solo se puede usar dentro de onMounted o después.

El flujo es el mismo que en React —datos hacia abajo, eventos hacia arriba— con una diferencia: en Vue se declara explícitamente en las dos direcciones.

Diferencias con React que merecen señalarse:

La declaración de emits es valiosa por una razón poco obvia: documenta el contrato completo del componente. Leyendo defineProps y defineEmits sabes todo lo que entra y todo lo que sale, sin buscar por el fichero qué funciones se llaman. En React esa información está repartida por la firma y hay que reconstruirla.

Y la misma regla que en React: las props son de solo lectura. Modificar props.tarea.estado desde el hijo es un error, y Vue avisa en desarrollo. El hijo emite; el padre decide.

Los slots son el equivalente de children de React, y son más expresivos porque admiten varios huecos con nombre.

Y los slots con ámbito, que permiten al hijo pasar datos al contenido que aporta el padre:

Es un patrón muy potente: el componente aporta la lógica (el bucle, las claves, el filtrado) y quien lo usa aporta la presentación. En React el equivalente se hace pasando una función como prop, y funciona igual de bien; la diferencia es de sintaxis, no de capacidad.

El equivalente de Context de React: poner un valor a disposición de todo el subárbol.

Y una diferencia técnica con Context que importa: como Vue tiene reactividad de grano fino, proveer un ref no repinta a todos los que hacen inject. Solo se actualizan los que realmente leen su .value. El problema de rendimiento de Context que describía 10-03 —todos los consumidores se repintan cuando cambia el valor— sencillamente no existe aquí.

readonly es una buena práctica: los descendientes leen el valor y para cambiarlo llaman a la función provista. Así el control del estado se queda donde debe.

Un composable es una función que usa el API de reactividad de Vue y devuelve estado y operaciones. Es el equivalente exacto de los hooks personalizados de 10-02, con una diferencia importante: no tiene reglas de orden de llamada, porque Vue no identifica el estado por posición sino por objeto.

Compara avanzar con su equivalente de React en 10-02:

Esta es la diferencia práctica más visible entre los dos frameworks. En React la inmutabilidad es obligatoria porque la detección es por referencia; en Vue el proxy detecta la escritura en la propiedad, así que mutar es correcto y natural. Ninguna de las dos es mejor: React gana en previsibilidad —el estado nunca cambia bajo tus pies y las comparaciones son triviales— y Vue gana en concisión y en el hecho de que las 599 tareas que no cambian ni siquiera se tocan.

Una convención sobre nombres: el ecosistema Vue usa useAlgo en inglés, igual que React. Aquí se escriben usarTablero y usarFiltroResponsable por coherencia con el resto del curso, pero en código real verás useTablero. Lo que importa es que sea consistente.

Pinia es el almacén oficial de Vue, y su versión mínima es sorprendentemente parecida a un composable:

storeToRefs es imprescindible y es una aplicación directa del límite 1 del apartado 15: desestructurar el almacén copiaría los valores y rompería la reactividad. storeToRefs convierte el estado y los derivados en refs vinculados; las acciones son funciones normales y se pueden desestructurar sin problema.

Comparado con Redux (10-03):

La conclusión de 10-03 se mantiene: empieza sin almacén. Un composable con un ref en un módulo ya es estado compartido —porque un ref de módulo es un objeto único—, y a menudo basta. Pinia añade DevTools, sustitución en caliente, la garantía de una única instancia y soporte para renderizado en servidor. La diferencia con Redux es que el escalón es mucho más bajo: pasar de un composable a un almacén Pinia son diez minutos.

Esa columna de la izquierda explica por qué se dice que Vue tiene menos fragmentación, y merece un análisis honesto en las dos direcciones.

Ventajas reales: hay una respuesta canónica a cada pregunta; la documentación oficial cubre el conjunto y los ejemplos encajan entre sí; las actualizaciones están coordinadas; dos proyectos Vue de empresas distintas se parecen bastante, con lo que incorporarse a uno es más rápido; y no hay que dedicar una semana a evaluar cuatro librerías de enrutado.

Desventajas reales: menos innovación desde fuera, porque hay menos incentivo para competir con la solución oficial; menos opciones cuando tu caso es raro; y un ecosistema de terceros más pequeño en números absolutos —para una necesidad muy específica es más probable encontrar una librería React que una Vue—.

Es el eje librería-framework de 10-01 con Vue situado en el medio: más opiniones que React, menos que Angular. Y también aquí conviene desconfiar de las conclusiones automáticas: la fragmentación de React es un coste para un equipo pequeño y una ventaja para uno que necesita algo poco común.

La pantalla objetivo del módulo, tercera versión. El dominio es el mismo fichero JavaScript de 10-02 y 10-03, sin tocar:

El filtro:

La tarjeta es la del apartado 4. Y la lista:

Y la aplicación:

Los números canónicos, verificados: sin filtro, «6 de 6 tareas · 45 h abiertas». Con «Iván», «3 de 6 · 25 h». Con «Lucía», «1 de 6 · 14 h». Con «Marta», «2 de 6 · 6 h». Y al pulsar «Empezar» en la tarea 6, avanzar muta tarea.estado, el proxy avisa a los computed que leyeron esa propiedad, y se actualizan solo la tarjeta afectada y el resumen. Las otras cinco tarjetas no se vuelven a ejecutar siquiera.

La tabla de las tres versiones de la misma pantalla:

Y las métricas de la misma pantalla:

Y el balance cualitativo, sin declarar ganadores:

Vue gana en: concisión (menos ceremonia para lo mismo), estilos aislados sin convenciones de nombres, reactividad automática que elimina el array de dependencias, computed como forma natural en lugar de optimización, un ecosistema oficial coherente y una curva de aprendizaje más suave para quien viene de HTML y CSS.

React gana en: tamaño del mercado laboral y del ecosistema de terceros, un modelo mental más simple de explicar (es una función que se reejecuta), «todo es JavaScript» sin sintaxis de plantilla que aprender, mejor soporte de herramientas de terceros, y React Native para móvil nativo.

JavaScript puro gana en: cero dependencias, cero peso de motor, cero compilación obligatoria, control absoluto y un código que seguirá funcionando dentro de diez años sin actualizar nada.

Las contrapartidas de Vue, dichas con claridad: la reactividad automática falla en silencio cuando se pierde (apartado 15), y el fallo es «no se actualiza», que es más difícil de diagnosticar que un error; la sintaxis de plantilla es un lenguaje adicional que hay que aprender y que las herramientas genéricas no entienden sin complementos; y el mercado laboral es más pequeño que el de React en la mayoría de sitios, lo cual es un criterio legítimo aunque no sea técnico.

Olvidar .value en el script. El error número uno. En la plantilla se desenvuelve solo, en el script no. if (responsable === 'Iván') compara un objeto ref con una cadena y siempre es falso, sin error. La regla de ESLint del complemento oficial de Vue lo detecta: actívala.

Desestructurar un objeto reactivo o un almacén de Pinia. const { responsable } = filtros copia el valor y rompe el vínculo. Usa toRefs para objetos reactivos y storeToRefs para almacenes.

Leer valores reactivos fuera del contexto de seguimiento. Dentro de un setTimeout, un .then() o un manejador registrado a mano, la lectura no se registra. Lee el valor antes, en el cuerpo del efecto.

Usar watch para derivar valores. Es el mismo antipatrón que useEffect para derivar estado en React: dos fuentes de verdad y un instante de desfase. Si es un valor, es computed.

Confundir v-if con v-show. v-show deja los nodos en el DOM: con 600 tareas, 600 nodos ocultos, encontrables con Ctrl+F, con el coste de memoria y de árbol de accesibilidad que mediste en 09-04. Para filtrar, v-if.

Usar el índice como :key. El mismo error que en React y que en tu reconciliar. Si la lista se filtra o se reordena, los nodos cambian de dato y se pierden el foco y el estado interno.

Olvidar .prevent en los formularios. @submit sin .prevent recarga la página. Es tan frecuente que Vue hizo el modificador precisamente por eso.

Olvidar .number en los campos numéricos. <input type="number" v-model="horas"> guarda una cadena. La validación de la R3 (horas > 0 && horas <= 40) compararía texto. Usa v-model.number.

Mutar props desde el hijo. Vue avisa en desarrollo. El hijo emite un evento; el padre decide qué hacer. Es el flujo unidireccional, que v-model no rompe sino que formaliza.

Creer que v-model es magia bidireccional. Es un v-bind más un v-on. Entenderlo así evita esperar comportamientos que no existen.

Consejo: usa ref por defecto y reactive solo cuando lo justifiques. ref funciona con cualquier tipo, se puede reemplazar entero, y el .value hace visible dónde está la reactividad.

Consejo: mantén el dominio fuera de los componentes. dominio/reglas.js es el mismo fichero en las tres versiones de esta pantalla, y esa es la mejor prueba de que la disciplina de 10-01 funciona: al cambiar de framework solo se reescribe la vista.

Consejo: instala Vue DevTools desde el primer día. Permite inspeccionar el árbol de componentes, ver el valor de cada ref y cada computed en tiempo real, y —muy útil— ver qué dependencias tiene registradas cada efecto, que es la forma directa de diagnosticar una reactividad perdida.

Este componente tiene cuatro fallos de reactividad. Encuéntralos, explica por qué falla cada uno y escribe la versión corregida.

Escribe un composable usarTareasRemotas(responsable) que:

1. Reciba un ref con el responsable filtrado.
2. Cargue las tareas del servidor con tu listarTareas de 07-02 cada vez que cambie el responsable.
3. Exponga tareas, cargando y error como refs.
4. Cancele la petición anterior al lanzar una nueva y al desmontar el componente, evitando la condición de carrera de 10-02.
5. Exponga también un computed con las horas abiertas de las tareas cargadas.

Después, explica por qué esta versión no necesita ningún array de dependencias y qué error de React se evita con ello.

Sin escribir código nuevo, rellena esta tabla comparando el mismo cambio funcional en las tres versiones de la pantalla que has visto en el módulo: añadir un badge que muestre el esfuerzo ponderado de cada tarea (horasEstimadas × PESOS[prioridad]), con fondo rojo si supera 30.

Después responde: en la versión de JavaScript puro, ¿qué pasaría si añadieras el badge a pintarTarjeta pero olvidaras añadirlo también al <template> de index.html?

Solución 1

Fallo 1 · const { responsable } = filtros (línea 6). Desestructurar un objeto reactive copia el valor primitivo null y pierde el vínculo. responsable valdrá null para siempre, así que visibles nunca filtrará nada aunque el usuario cambie el <select>. Es el límite 1 del apartado 15.

Fallo 2 · watch para derivar horasAbiertas. Es el antipatrón del apartado 18: dos fuentes de verdad, un instante de desfase y más código. Además, como tareas es un ref a un array y el watch no es profundo, mutar el estado de una tarea no dispara el watch: horasAbiertas se quedaría obsoleta al marcar una tarea como hecha, que es justamente el caso de uso principal.

Fallo 3 · Lectura dentro de un setTimeout en el computed. La lectura de filtros.texto ocurre después de que el computed haya terminado, fuera del contexto de seguimiento: no se registra como dependencia. Además, un computed no debe tener efectos secundarios: debe ser una función pura de sus dependencias, igual que tus reductores de 10-03.

Fallo 4 · filtros = { … } en limpiar. Reasignar un objeto reactive rompe el vínculo con la plantilla, que sigue apuntando al proxy original. Además, filtros está declarado con const, así que esto lanzaría un TypeError en tiempo de ejecución (01-05).

Versión corregida:

Nota sobre la desestructuración de la línea const { responsable, texto } = filtros.value: aquí sí es correcta, porque ocurre dentro del computed. La lectura de filtros.value registra la dependencia en ese momento; lo que se desestructura después son valores ya leídos, usados inmediatamente. La regla no es «nunca desestructures», sino «no guardes valores desestructurados fuera de un contexto reactivo».

Solución 2

Uso:

Por qué no hace falta array de dependencias. El watchEffect lee responsable.value durante su ejecución, y el proxy registra esa lectura automáticamente. Cuando el valor cambia, el efecto se vuelve a ejecutar — después de haber llamado a la limpieza, que aborta la petición en vuelo.

Qué error de React se evita. Dos, en realidad:

1. La dependencia olvidada. En React, escribir }, []) en lugar de }, [responsable]) produce un componente que carga una vez y nunca se actualiza. Es tan frecuente que existe una regla de ESLint específica para ello. Aquí es imposible por construcción.
2. La dependencia que cambia siempre. Si en React pasaras un objeto { responsable } como dependencia, se recrearía en cada renderizado y la petición se lanzaría infinitamente. En Vue las dependencias son los valores reactivos leídos, no referencias comparadas.

Y un aviso, para no vender humo: hay un caso donde el seguimiento automático de Vue también falla. Las lecturas que ocurren después de un await no se registran, porque el contexto de seguimiento se cierra al suspenderse la función. Por eso el código lee responsable.value antes del await, dentro de la llamada. Si necesitaras leer otro ref después del await, tendrías que leerlo antes y guardarlo. Es el mismo límite del apartado 15, en su forma más sutil.

Solución 3

Qué pasa si olvidas el <span> en el <template> de index.html. Depende de cómo esté escrito pintarTarjeta. Si usa $('.tarea__esfuerzo', li).textContent = …, el selector devuelve null y la línea lanza un TypeError: Cannot set properties of null en tiempo de ejecución, al pintar la primera tarjeta: la aplicación se rompe entera. Si en cambio comprueba antes (const badge = $('.tarea__esfuerzo', li); if (badge) …), no pasa nada visible: el badge simplemente no aparece, sin ningún error, y el fallo solo se detecta mirando la pantalla o con una prueba de extremo a extremo (08-06).

Ese es, con nombres y apellidos, el acoplamiento sin comprobar del que hablaba el apartado 13 de 10-01. En la versión Vue el error es imposible: el marcado y el código que lo rellena son el mismo fichero, y el compilador de plantillas avisa si una variable no existe.

Has visto Vue en su versión moderna —Composition API y <script setup>— y, sobre todo, has visto el segundo modelo de reactividad de 10-01 funcionando de verdad.

Sabes qué significa framework progresivo y lo has comprobado: los mismos conceptos sirven para mejorar una página existente con una etiqueta <script> y sin compilar, o para montar una aplicación completa con Vite, Vue Router y Pinia. Conoces los Componentes de un Solo Fichero con sus tres bloques y por qué agrupar plantilla, lógica y estilos no viola la separación de intereses sino que la respeta: la estructura, el aspecto y el comportamiento de una tarjeta son un solo interés, y el <style scoped> convierte el aislamiento en una garantía del compilador en lugar de una convención de nombres.

Dominas la sintaxis de plantilla: la interpolación con su escapado automático, v-bind con las formas de objeto para clases y estilos —cuatro instrucciones imperativas de classList reducidas a una descripción—, v-on con sus modificadores que codifican el preventDefault y el stopPropagation de 06-03, la diferencia entre v-if y v-show —crear y destruir frente a display: none, con los 7.812 nodos frente a 1.194 que mediste en 09-04—, v-for con :key, que por tercera vez en el módulo es tu data-id de 06-06, y v-model desmitificado: un v-bind que baja el valor y un v-on que lo sube, el formulario controlado de 10-02 escrito en una línea, con .trim y .number que evitan errores reales en las reglas R2 y R3.

Entiendes la reactividad por dentro. Sabes por qué existe .value —JavaScript no permite interceptar la asignación a una variable, solo a una propiedad— y que un ref es un objeto con get/set interceptados, exactamente el mecanismo de 05-03. Sabes cómo los proxies registran las dependencias durante la ejecución de un efecto, con sus tres consecuencias: detección automática y precisa, detección dinámica que ignora las ramas no tomadas, y detección solo durante la ejecución — de donde salen los cuatro límites donde la reactividad se pierde: desestructurar un objeto reactivo, desestructurar props, pasar un primitivo a una función y reemplazar un reactive entero, con toRefs y storeToRefs como herramientas. Y tienes la comparación honesta: React te obliga a declarar dependencias y por eso puede comprobarlas con ESLint; Vue las descubre solo y por eso el fallo es silencioso.

Sabes que computed es tu caché por versión de 09-02 con la invalidación descubierta automáticamente —veinte líneas y un riesgo de olvido convertidos en una línea sin riesgo—, y que a diferencia de useMemo no es una optimización sino la forma natural de escribir derivados. Distingues watch y watchEffect con el criterio para elegir entre los tres, y reconoces el antipatrón de derivar con watch como el mismo error que derivar con useEffect. Conoces el ciclo de vida con onMounted y onUnmounted, que vuelve a ser tu destruir() con la llamada garantizada pero el contenido a tu cargo.

Sabes comunicar componentes con props y emits declarados —un contrato completo y validado que se lee en dos líneas—, componer contenido con slots con nombre y con ámbito, e inyectar valores con provide/inject, que a diferencia de Context no repinta a todos los consumidores porque la reactividad es de grano fino. Extraes lógica en composables sin reglas de orden de llamada, y sabes que la diferencia práctica más visible con React está en avanzar: donde React exige un map inmutable, Vue muta la propiedad y el proxy hace el resto. Conoces Pinia en su versión mínima —casi idéntica a un composable, con storeToRefs como requisito— y el ecosistema oficial que explica la menor fragmentación de Vue, con sus ventajas y sus costes.

Y has visto la tercera versión de la misma pantalla, con el mismo dominio/reglas.js sin tocar en las tres, ~120 líneas, un solo fichero por componente con sus estilos aislados, y actualizaciones que tocan solo lo que ha cambiado. Con las contrapartidas dichas: la reactividad perdida falla en silencio, la sintaxis de plantilla es un lenguaje más, y el mercado laboral es más pequeño.

Quedan dos modelos por ver. El siguiente es el más distinto de todos: un framework que no es una librería ni un framework progresivo sino una plataforma completa, con TypeScript como requisito de hecho, inyección de dependencias, una CLI que genera todo, observables para los flujos asíncronos, y —desde hace poco— señales muy parecidas a los ref que acabas de aprender. Es el extremo «con opiniones» del eje de 10-01: Conceptos Básicos de Angular.