Store Pinia propre : structure et pratiques

Structure propre des stores Pinia : Meilleures pratiques éprouvées

Dans les gros projets Vue, les stores Pinia gonflent souvent, rendant la maintenance cauchemardesque. Une structure solide règle ça : mutations uniquement via actions, syntaxe setup, et pas d'effets de bord dans le store. Ça garde tout prévisible et testable pour les devs intermédiaires à seniors.

Mutations uniquement via actions

Muter directement l'état depuis les composants brouille les responsabilités. Voici du code problématique :

const docStore = useDocumentStore()
const { client } = storeToRefs(docStore)
client.value = null // Logique de mutation éparpillée

Avec le temps, le debug devient impossible car les changements sont disséminés dans les composants. La solution ? Des actions centralisées :

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

// Dans le composant
 docStore.resetClient()

Un point d'entrée unique facilite l'ajout de validation, logging ou analytics sans toucher au code partout.

Stores en syntaxe setup plutôt qu'Options API

L'Options API est dépassée pour les stores. La syntaxe setup (defineStore(() => { ... })) offre :

• Réactivité transparente sans this.
• Tests plus simples.
• Intégration fluide avec les composables.

Moins de boilerplate, réactivité comme dans les composants. Pour les nouveaux stores, passez-y : la différence est immédiate.

Oubliez les watchers dans les stores

Les watchers dans les stores déclenchent des effets de bord cachés lors des changements d'état, compliquant le debug. Les stores doivent juste contenir les données, sans dispatching d'événements.

Remplacez-les par des appels explicites depuis les composants ou composables. Gérez les changements de route, parsing d'URL ou événements externes dehors, en passant les données prêtes via actions.

Persistance via plugins

Synchroniser avec localStorage ne doit pas se mélanger à la logique métier. Utilisez pinia-plugin-persistedstate ou un wrapper custom testé.

Évitez localStorage.setItem direct dans les actions : ça casse la pureté du store et gêne le refactoring.

Stores comme purs conteneurs de données

Les stores gèrent seulement lecture, sauvegarde et mise à jour des données. Sortez :

• Abonnements au routeur.
• Parsing de tokens.
• Logique WebSocket.
• Calculs inter-stores.

Checklist pré-commit :

• Pourrais-je remplacer ce store par un simple fichier de constantes et fonctions sans casser l'architecture ?
• Sinon, il est surchargé : extrayez la logique.

Points clés

• Mutations centralisées : Actions plutôt qu'accès direct aux refs.
• Syntaxe setup : Tests faciles, pas de this.
• Pas de watchers : Effets de bord dehors, store prévisible.
• Persistance séparée : Plugins, pas dans les actions.
• Responsabilité unique : Logique complexe vers composables.

Cette approche garde les stores légers, mockables et refactor-friendly. Les projets restent maintenables, et l'habitude prend vite.

— Editorial Team