Pinia Vue चा अधिकृत state-management लायब्ररी आहे (Vuex चा उत्तराधिकारी) — एक केंद्रीभूत store जो अनेक घटकांमध्ये सामायिक केलेल्या स्टेटसाठी आहे, Composition API वर बनविलेल्या सोप्या, type-safe API सह.
{ defineStore } ;
{ ref, computed } ;
useCounterStore = (, {
count = ();
double = ( count. * );
() { count.++; }
() { count. = api.(); }
{ count, double, increment, fetchInitial };
});
हा "setup store" composable सारखाच दिसतो — स्टेटसाठी ref, getters साठी computed, actions साठी फंक्शन्स — ज्यामुळे 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>
महत्वाचे: state/getters destructure करताना storeToRefs वापरा — साधारण destructuring reactivity तोडेल (तेच reactive caution जसे reactive). Actions साठी हे आवश्यक नाही.
✓ 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 Vue apps मधील global, shared state साठी मानक समाधान आहे — user/auth, shopping carts, app settings, cached data — कोणत्याही गोष्टीसाठी जी अनेक दूरस्थ घटकांनी सातत्याने वाचणे आणि अपडेट करणे आवश्यक आहे.
त्याची composable-style API, first-class TypeScript support, आणि Vuex चे boilerplate नसल्यामुळे हे अनुशंसित पर्याय आहे.
ते कधी वापरायचे हे जाणून घेणे (props/inject विरुद्ध) जेव्हा state खरोखर global असेल, आणि destructure केल्यावर reactivity जतन करण्यासाठी storeToRefs वापरणे, हे त्याच्या योग्य उपयोगाचे मूल आहे.