Pinia is the official Vue store and the one interviewers assume. The questions are predictable: setup versus option stores, what happens to a store during SSR, why destructuring a store loses reactivity, how you test one, and, for seniors, when not to reach for it. Pinia 4 (ESM-only) is current as of September 2026, installed in Nuxt through @pinia/nuxt.

Know

• Two syntaxes. Option stores: defineStore('cart', { state: () => ({}), getters: {}, actions: {} }). Setup stores: defineStore('cart', () => { const items = ref([]); const total = computed(...); function add() {} ; return { items, total, add } }). Setup stores read like composables, allow watchers and other composables inside, and are what most teams standardise on; option stores get $reset() for free and are easier to migrate from Vuex.
• storeToRefs(store) extracts reactive refs for state and getters; destructuring the store directly (const { items } = useCartStore()) copies plain values and loses reactivity. Actions can be destructured because they are functions.
• SSR in Nuxt: @pinia/nuxt creates one Pinia per request on the server and injects it into the app; the state is serialised into the payload (nuxtApp.payload.pinia) and hydrated on the client, so a store filled during SSR is already populated in the browser. Calling useStore() works anywhere in the Nuxt context (pages, middleware, plugins); outside it, pass the instance explicitly (useStore(useNuxtApp().$pinia)).
• API surface: $patch(object | fn) for batched mutations, $reset() (option stores; implement your own in setup stores), $subscribe(cb, { detached }) for state changes, $onAction for action hooks, $state to replace state wholesale, $dispose. Plugins via pinia.use() add properties, options or persistence to every store.
• Persistence: pinia-plugin-persistedstate (with its Nuxt module) stores selected picked paths in cookies (SSR-visible) or localStorage/sessionStorage (client only, restored after hydration). Cookies are size-limited; do not persist server data or secrets.
• Composition: stores can use other stores inside getters and actions (useUserStore() inside useCartStore); avoid two stores reading each other's state in getters cyclically.
• Testing: @pinia/testing's createTestingPinia({ stubActions, initialState, createSpy }) gives an active Pinia with actions stubbed as spies, so components can be tested against store state without hitting APIs; unit-test a store directly with setActivePinia(createPinia()).
• Pinia 4 contains only technical breaking changes: ESM-only distribution, and @vue/devtools-api (v8) must be installed alongside; @pinia/nuxt 1.x pairs with it. Pinia Colada is the companion data-fetching layer (see the next page).
• When not to use a store: for local UI state (a modal's open flag), for server data (that is a cache concern), or for anything only one component reads. A store is a global singleton per app; every consumer couples to it.

How it works

A setup store with everything an interviewer expects to see, SSR-safe:

import { defineStore } from 'pinia'

export interface CartItem { id: string, name: string, price: number, qty: number }

export const useCartStore = defineStore('cart', () => {
  const items = ref<CartItem[]>([])
  const coupon = ref<string | null>(null)

  const count = computed(() => items.value.reduce((n, i) => n + i.qty, 0))
  const subtotal = computed(() => items.value.reduce((n, i) => n + i.price * i.qty, 0))
  const total = computed(() => (coupon.value === 'TEN' ? subtotal.value * 0.9 : subtotal.value))

  function add(item: Omit<CartItem, 'qty'>, qty = 1) {
    const existing = items.value.find(i => i.id === item.id)
    if (existing) existing.qty += qty
    else items.value.push({ ...item, qty })
  }

  function remove(id: string) {
    items.value = items.value.filter(i => i.id !== id)
  }

  async function checkout() {
    // Server owns the order; the store only holds the client-side cart.
    const order = await $fetch('/api/orders', { method: 'POST', body: { items: items.value, coupon: coupon.value } })
    $reset()
    return order
  }

  // Setup stores have no automatic $reset: provide one.
  function $reset() {
    items.value = []
    coupon.value = null
  }

  return { items, coupon, count, subtotal, total, add, remove, checkout, $reset }
}, {
  // pinia-plugin-persistedstate: cookie so the server render sees the cart too
  persist: { pick: ['items', 'coupon'], storage: piniaPluginPersistedstate.cookies({ maxAge: 60 * 60 * 24 * 7 }) },
})

Using it without losing reactivity, and hydrating it on the server:

<script setup lang="ts">
import { storeToRefs } from 'pinia'

const cart = useCartStore()
const { count, total } = storeToRefs(cart) // refs; `const { count } = cart` would be a frozen number
const { add } = cart // actions are plain functions and can be destructured
</script>

<template>
  <button type="button" @click="add({ id: 'sku-1', name: 'Sample', price: 9 })">
    {{ count }} items · {{ total.toFixed(2) }}
  </button>
</template>

export default defineNuxtPlugin(async () => {
  // Runs per request on the server; the resulting store state travels in the payload.
  const user = useUserStore()
  if (import.meta.server) await user.loadFromSession()
})

Testing a component against store state:

import { mountSuspended } from '@nuxt/test-utils/runtime'
import { createTestingPinia } from '@pinia/testing'
import { describe, expect, it } from 'vitest'
import CartBadge from '~/components/Cart/Badge.vue'

describe('CartBadge', () => {
  it('shows the count from the store', async () => {
    const wrapper = await mountSuspended(CartBadge, {
      global: {
        plugins: [createTestingPinia({ initialState: { cart: { items: [{ id: '1', name: 'A', price: 2, qty: 3 }] } } })],
      },
    })
    expect(wrapper.text()).toContain('3 items')
  })
})

Exercise

Be able to say