Pinia est la bibliothèque officielle de gestion d'état de Vue (la successeur de Vuex) — un store centralisé pour l'état qui doit être partagé entre de nombreux composants, avec une API simple et type-safe basée sur la Composition API.
{ defineStore } ;
{ ref, computed } ;
useCounterStore = (, {
count = ();
double = ( count. * );
() { count.++; }
() { count. = api.(); }
{ count, double, increment, fetchInitial };
});
Ce « setup store » ressemble exactement à un composable — ref pour l'état, computed pour les getters, les fonctions pour les actions — ce qui le rend intuitif si vous connaissez la Composition API.
<script setup>
import { useCounterStore } from "@/stores/counter";
import { storeToRefs } from "pinia";
const store = useCounterStore();
const { count, double } = storeToRefs(store); // keep state reactive when destructured
const { increment } = store; // actions can be destructured directly
</script>
<template>
<button @click="increment">{{ count }} (x2 = {{ double }})</button>
</template>
Important : utilisez storeToRefs lors du destructuring de l'état/getters — le destructuring simple casserait la réactivité (même mise en garde réactive que reactive). Les actions n'en ont pas besoin.
✓ No mutations boilerplate — actions can mutate state directly
✓ Excellent TypeScript inference (Vuex was painful to type)
✓ Modular by design — many small stores, no nested-module complexity
✓ Composition-API-native, tiny API, devtools support
props/emits → parent ↔ child
provide/inject → share within a subtree
Pinia store → GLOBAL/app-wide shared state (auth user, cart, settings)
accessed by many unrelated components
Pinia est la solution standard pour l'état global et partagé dans les applications Vue — utilisateur/authentification, paniers d'achat, paramètres de l'application, données en cache — tout ce que de nombreux composants éloignés doivent lire et mettre à jour de manière cohérente.
Son API de style composable, le support TypeScript natif et l'absence de boilerplate de Vuex en font le choix recommandé.
Savoir quand le choisir (par rapport aux props/inject) quand l'état est vraiment global, et utiliser storeToRefs pour préserver la réactivité lors du destructuring, est l'essence de son utilisation correcte.