¿Cuándo un composable reutilizable mejora el diseño y cuándo solo se convierte en una bolsa de efectos secundarios?

Respuesta

• Un composable compensa cuando encapsula un comportamiento repetido con dependencias explícitas y una API estable.
• Si dentro del mismo useX mezclas fetch, caché, navegación, analytics y permisos, ya no tienes una abstracción pequeña sino varias preocupaciones pegadas.
• La prueba rápida es preguntar si otro desarrollador podría usar ese composable sin leer su código interno.

Puntos clave

• La decisión correcta en Vue casi siempre depende del alcance del problema: componente, subárbol, feature o aplicación completa.
• Una buena arquitectura deja dependencias visibles, reduce puntos de escritura y mantiene cerca del caso de uso lo que cambia junto.
• Si una solución necesita demasiadas capas para explicar algo pequeño, probablemente está modelando peor el problema, no mejor.

Errores comunes

• Crear una capa “shared” enorme donde cabe todo acaba destruyendo justo el aislamiento que se buscaba.
• Escoger mecanismo por moda en vez de por alcance suele dejar soluciones más difíciles de leer que de cambiar.

Ejemplo de código

export function useUserSearch() {
  const query = ref("");
  const results = ref<User[]>([]);

  watch(query, async (value, _, onCleanup) => {
    const controller = new AbortController();
    onCleanup(() => controller.abort());
    results.value = await fetchUsers(value, controller.signal);
  });
}

Ejemplo o caso real

Esto suele aparecer en features vivas del producto donde cada cambio pequeño empieza a tocar demasiados componentes, composables o stores.

Idea clave

La mejor arquitectura en Vue es la que reduce dependencias hoy y sigue siendo explicable mañana.