Pinia es la biblioteca oficial de gestión de estado de Vue (la sucesora de Vuex) — un store centralizado para el estado que necesita compartirse entre muchos componentes, con una API simple y segura en tipos construida sobre la Composition API.
{ defineStore } ;
{ ref, computed } ;
useCounterStore = (, {
count = ();
double = ( count. * );
() { count.++; }
() { count. = api.(); }
{ count, double, increment, fetchInitial };
});
Este "setup store" se ve exactamente como un composable — ref para el estado, computed para getters, funciones para actions — lo que lo hace intuitivo si conoces 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>
Importante: usa storeToRefs cuando destructures estado/getters — la desestructuración normal rompería la reactividad (la misma advertencia reactiva que reactive). Los actions no la necesitan.
✓ 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 es la solución estándar para el estado global compartido en aplicaciones Vue — usuario/autenticación, carritos de compra, configuración de la aplicación, datos en caché — cualquier cosa que muchos componentes distantes deben leer y actualizar consistentemente.
Su API de estilo composable, soporte TypeScript de primera clase y la falta de boilerplate de Vuex la hacen la opción recomendada.
Saber cuándo recurrir a ella (vs props/inject) cuando el estado es realmente global, y usar storeToRefs para preservar la reactividad al desestructurar, es el núcleo de usarla correctamente.