Store Pinia limpio: estructura y prácticas

Estructura Limpia de Stores Pinia: Mejores Prácticas Comprobadas

En proyectos Vue grandes, los stores de Pinia suelen inflarse de tamaño, convirtiendo el mantenimiento en una pesadilla. Una estructura sólida lo soluciona: mutaciones solo a través de acciones, sintaxis de setup y sin efectos secundarios dentro del store. Esto mantiene todo predecible y testable para desarrolladores intermedios y senior.

Mutaciones Solo a Través de Acciones

Mutar el estado directamente desde componentes difumina las responsabilidades. Aquí va un código problemático:

const docStore = useDocumentStore()
const { client } = storeToRefs(docStore)
client.value = null // Lógica de mutación dispersa

Con el tiempo, depurar se vuelve imposible porque los cambios están repartidos por todos los componentes. ¿La solución? Acciones centralizadas:

export const useDocumentStore = defineStore('documents', () => {
  const client = ref(null)
  const resetClient = () => { client.value = null }
  return { client, resetClient }
})

// En el componente
 docStore.resetClient()

Un único punto de entrada facilita agregar validaciones, logging o analíticas sin tocar código por todos lados.

Stores de Setup en Lugar de Options API

Options API está pasado de moda para stores. El estilo de setup (defineStore(() => { ... })) ofrece:

• Reactividad transparente sin this.
• Pruebas más sencillas.
• Integración fluida con composables.

Menos boilerplate, reactividad igual que en componentes. Para stores nuevos, el cambio es imprescindible: la diferencia se nota al instante.

Elimina los Watchers en los Stores

Los watchers dentro de stores activan efectos secundarios ocultos al cambiar el estado, complicando la depuración. Los stores deben solo contener datos, nada de disparar eventos.

Reemplaza watchers con llamadas explícitas desde componentes o composables. Maneja cambios de ruta, parsing de URL o eventos externos afuera, pasando datos listos vía acciones.

Persistencia con Plugins

Sincronizar con localStorage no debe mezclarse con la lógica de negocio. Usa pinia-plugin-persistedstate o un wrapper personalizado probado.

Evita localStorage.setItem directo en acciones: rompe la pureza del store y complica refactorizaciones.

Stores como Puros Contenedores de Datos

Los stores solo manejan lectura, guardado y actualización de datos. Saca afuera:

• Suscripciones al router.
• Parsing de tokens.
• Lógica de WebSocket.
• Cálculos entre stores.

Lista de verificación pre-commit:

• ¿Podría reemplazar este store por un archivo plano de constantes y funciones sin romper la arquitectura?
• Si no, está sobrecargado: extrae la lógica.

Resumen de Claves

• Mutaciones centralizadas: Acciones en vez de acceso directo a refs.
• Sintaxis de setup: Pruebas fáciles, sin this.
• Sin watchers: Efectos secundarios afuera, store predecible.
• Persistencia separada: Plugins, no en acciones.
• Responsabilidad única: Lógica compleja a composables.

Este enfoque mantiene los stores livianos, mockeables y aptos para refactorizar. Los proyectos siguen siendo mantenibles, y el hábito se pega rápido.

— Editorial Team