En una PR Vue importante, ¿qué anti-patrones de reactividad, tipado y acoplamiento revisarías antes de aprobar?

Respuesta

• Busca copias locales de estado, derivación montada con watchers y dependencias implícitas con router o store que no aparecen en la API del componente.
• Revisa props, emits y contratos de store para detectar any, casts rápidos o tipos demasiado laxos que dejen pasar estados inválidos.
• Valora si la PR deja el flujo del dato más claro o simplemente reparte complejidad en más archivos con nombres mejores.

Puntos clave

• En una PR Vue conviene seguir el flujo del dato antes que el flujo visual: quién lee, quién escribe, quién deriva y quién dispara efectos.
• Las señales más caras suelen ser copias locales innecesarias, watchers para derivación, casts que ocultan tipos débiles y dependencias implícitas.
• Una buena revisión piensa en el siguiente cambio de producto, no solo en si el caso feliz actual funciona.

Errores comunes

• Aprobar código que “funciona” pero no explica su contrato visible traslada la complejidad al siguiente sprint.
• Mirar solo naming y estilo deja pasar la mayoría de problemas serios de acoplamiento y reactividad.

Ejemplo de código

const store = useUsersStore();
const { users } = store;

watch(users, () => {
  localCache.value = users;
}, { deep: true });

Ejemplo o caso real

En revisión se nota especialmente en PRs grandes donde la funcionalidad parece cerrar el caso feliz, pero el flujo del dato ya ha quedado innecesariamente opaco.

Idea clave

En una PR Vue miro primero el flujo del dato; el resto viene después.