¿Qué anti-patrones ves al abusar de `watch` para derivar estado o coordinar lógica entre componentes?

Respuesta

• El anti-patrón más común es usar watch para recomponer datos que deberían salir de un computed sencillo.
• Otro problema es enlazar watchers entre sí hasta crear un flujo de dependencias implícitas que nadie puede seguir con seguridad.
• Si un watch coordina lógica entre varios componentes, suele ser señal de que falta un owner claro o un contrato más explícito.

Puntos clave

• computed debe ser puro y servir para derivar; cuando introduces efectos laterales ahí, el modelo mental deja de ser fiable.
• watch y watchEffect son herramientas para sincronizar con el exterior, no para construir una cadena de estado derivado.
• En Vue conviene distinguir siempre fuente de verdad, dato derivado y efecto externo porque casi todos los bugs reactivos rompen una de esas fronteras.

Errores comunes

• Usar watchers para derivar datos que podrían salir de computed introduce sincronizaciones manuales y fallos difíciles de seguir.
• Copiar valores reactivos a variables locales sin toRefs o storeToRefs rompe la relación con la fuente de verdad.

Ejemplo de código

<script setup lang="ts">
import { computed, ref } from "vue";

const query = ref("");
const products = ref(["Vue", "Pinia", "Vitest"]);
const filtered = computed(() =>
  products.value.filter((item) => item.toLowerCase().includes(query.value.toLowerCase())),
);
</script>

Ejemplo o caso real

En una pantalla con filtros, carga remota y varios estados locales, estas decisiones afectan directamente a si la UI se mantiene estable o empieza a comportarse de forma impredecible.

Idea clave

Si separo fuente de verdad, derivación y efecto, la mayoría de problemas reactivos pierden fuerza.