Hvordan fungerer state management med Pinia?

Question

Accepted Answer

**Pinia** er Vues officielle state-management-bibliotek (Vuex's efterfølger) — et centraliseret **store** for state, der skal deles på tværs af mange komponenter, med et simpelt, typesikkert API bygget på Composition API. ## Definering af et 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 }; }); ``` Dette "setup store" ser ud præcis som et composable — `ref` for state, `computed` for getters, funktioner for actions — hvilket gør det intuitivt, hvis du kender Composition API. ## Brug af store i komponenter ```vue ``` **Vigtig:** brug `storeToRefs` når du dekonstruerer **state/getters** — normal dekonstruering ville ødelægge reaktiviteten (samme reaktive advarsel som `reactive`). Actions har ikke brug for det. ## Hvorfor Pinia frem for 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 ``` ## Hvornår skal man bruge et store i forhold til 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 ``` ## Hvorfor det betyder noget Pinia er standardløsningen for **global, delt state** i Vue-apps — bruger/autentificering, indkøbskurve, app-indstillinger, cachede data — alt hvad mange fjerne komponenter skal læse og opdatere konsistent. Dets composable-style API, førsteklasses TypeScript-support og mangel på Vuex's boilerplate gør den til det anbefalede valg. At vide hvornår man skal bruge den (i stedet for props/inject) når state er virkelig global, og at bruge `storeToRefs` for at bevare reaktivitet ved dekonstruering, er kernen i at bruge den korrekt.