How does state management with Pinia work?

Question

Accepted Answer

**Pinia** is Vue's official state-management library (the successor to Vuex) — a centralized **store** for state that needs to be shared across many components, with a simple, type-safe API built on the Composition API. ## Defining a store ```js // stores/counter.js import { defineStore } from "pinia"; import { ref, computed } from "vue"; export const useCounterStore = defineStore("counter", () => { // state const count = ref(0); // getters (derived state) = computed const double = computed(() => count.value * 2); // actions (methods that mutate state) function increment() { count.value++; } async function fetchInitial() { count.value = await api.getCount(); } return { count, double, increment, fetchInitial }; }); ``` This "setup store" looks exactly like a composable — `ref` for state, `computed` for getters, functions for actions — making it intuitive if you know the Composition API. ## Using the store in components ```vue ``` **Important:** use `storeToRefs` when destructuring **state/getters** — plain destructuring would break reactivity (same reactive caveat as `reactive`). Actions don't need it. ## Why Pinia over Vuex ```text ✓ 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 ``` ## When to use a store vs props/composables ```text 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 ``` ## Why it matters Pinia is the standard solution for **global, shared state** in Vue apps — user/auth, shopping carts, app settings, cached data — anything many distant components must read and update consistently. Its composable-style API, first-class TypeScript support, and lack of Vuex's boilerplate make it the recommended choice. Knowing to reach for it (vs props/inject) when state is truly global, and to use `storeToRefs` to preserve reactivity on destructure, is the core of using it correctly.