¿Qué criterio usarías para mover lógica de un componente a Pinia o dejarla local?

Respuesta

• Déjala local si solo afecta a la interacción de un componente o de una pantalla concreta y no necesita sobrevivir a la navegación.
• Muévela a Pinia cuando varias vistas dependan de ese dato, cuando el flujo cruce rutas o cuando la trazabilidad del estado compense el coste extra.
• Si el problema es solo reutilizar lógica, quizá necesitas un composable antes que un store global.

Puntos clave

• Pinia funciona mejor cuando el store guarda estado canónico, los getters derivan y las acciones concentran escrituras y asincronía.
• No todo estado merece ser global: inputs temporales, toggles locales o borradores efímeros suelen ser más claros cerca del componente.
• Cuando un dato existe en formulario, URL, caché y store, la pregunta correcta no es cómo sincronizarlo todo, sino quién debería ser el dueño.

Errores comunes

• Meter demasiado estado efímero en Pinia hace más opaco el flujo y complica la trazabilidad sin ganar nada real.
• Sin una política clara de invalidación, rollback o responsabilidad sobre el dato, el estado remoto acaba sobrescribiendo datos correctos en mal momento.

Ejemplo de código

export const useCartStore = defineStore("cart", {
  state: () => ({ items: [] as CartItem[], pending: false }),
  getters: {
    total: (state) => state.items.reduce((sum, item) => sum + item.price * item.qty, 0),
  },
  actions: {
    add(item: CartItem) {
      this.items.push(item);
    },
  },
});

Ejemplo o caso real

Se nota mucho en flujos donde conviven URL, borradores, caché y respuestas del servidor, porque cualquier responsabilidad ambigua sobre el dato termina enseñando un valor incorrecto.

Idea clave

Antes de sincronizar varios estados, decido quién debería ser el dueño real del dato.