Shared state with Pinia: stores that stay singular

Shared state with Pinia lives in an importable store, not in provide/inject: a component reads the store and does not know who else uses it. One store per domain, not one per component.

One store, one domain

The first argument of defineStore is the id: it is the key devtools and persistence plugins use to recognise the store. Two stores with the same id are the same store, even when you declare them in different files.

npm install pinia

// stores/cart.ts
import { computed, ref } from "vue";
import { defineStore } from "pinia";

export type CartItem = { id: string; qty: number; price: number };

export const useCart = defineStore("cart", () => {
  const items = ref([]);
  const count = computed(() => items.value.reduce((n, i) => n + i.qty, 0));
  const total = computed(() => items.value.reduce((n, i) => n + i.qty * i.price, 0));

  function add(item: CartItem) {
    const found = items.value.find((i) => i.id === item.id);
    if (found) found.qty += item.qty;
    else items.value.push({ ...item });
  }

  function clear() {
    items.value = [];
  }

  return { items, count, total, add, clear };
});

A setup store is a function: refs become state, computed values become getters, functions become actions. There is no mutation layer to write: the action changes the state, and devtools records the call.

// main.ts
import { createApp } from "vue";
import { createPinia } from "pinia";
import App from "./App.vue";

createApp(App).use(createPinia()).mount("#app");

storeToRefs: the line that keeps reactivity

Destructuring the store copies values and stops updates. storeToRefs returns connected refs for state and getters; actions are called on the store and never destructured, because they lose their context.

import { storeToRefs } from "pinia";
import { useCart } from "@/stores/cart";

const cart = useCart();
const { count, total } = storeToRefs(cart);



  
    Cart ({{ count }}) — {{ total.toFixed(2) }}
  

SSR: one instance per request

On the server an imported module is shared by every request. Call createPinia() at module level and one visitor's cart ends up in another visitor's page: create the instance inside the function that builds the app, once per request.

Where the store breaks

• Calling useCart() outside setup() with no active Pinia instance: the error only shows at runtime.
• Relying on $reset in a setup store: it exists in options stores, everywhere else you write it yourself.
• Persisting class instances with the persistence plugin: on reload they come back as plain objects, without methods.
• Keeping window or localStorage in the store body: during server rendering that code does not exist.

The limitation to plan for

Pinia is not a database: it does not deduplicate requests, does not sync two tabs and does not resolve conflicts. If two components write the same field, the last action wins. Persistence is a plugin you configure and test, not a promise of the framework.

The components that read the store are ready: Vuetify, shadcn-vue and the dashboard block bring markup and states, not the state. The base is in the Composition API; the case where reactivity is lost is in props that do not update, the comparison in Vue vs React.