Plugins & SSR — Series 2

Preview — 3 of 10 questions

Why does this component use count: 'count' style object syntax instead of the array form?

javascript

import { mapState, mapActions } from 'pinia'
import { useCounterStore } from './stores/counter'

export default {
  computed: {
    ...mapState(useCounterStore, {
      counterValue: 'count', // exposed as this.counterValue, reads store.count
      doubleValue: (store) => store.count * 2, // a function form, computed from the store
    }),
  },
  methods: {
    ...mapActions(useCounterStore, {
      addOne: 'increment', // exposed as this.addOne(), calls store.increment()
    }),
  },
}

AmapState/mapActions's object-syntax form lets each mapped property/method be exposed under a different local name than the store's own — counterValue rather than count, useful for avoiding naming collisions with other mapped stores/local data, or simply for a more descriptive local name. It also accepts a function ((store) => ...) as a value, for mapping a derived value rather than a direct passthrough — something the plain array form (mapState(useCounterStore, ['count']), which always keeps the original name) can't express

BThe object form only exists for backward compatibility with Vuex — it's discouraged in new Pinia code, which should always use the plain array form

CThe object form maps every property in the store automatically — the actual key names provided (counterValue, doubleValue) are ignored

DmapActions's object form can only rename actions, never functions passed inline like doubleValue above — that part of the example is invalid

Why does this composable prevent a consuming component from directly mutating the cart, while still letting it read live data?

javascript

// composables/useCartView.js
import { readonly } from 'vue'
import { storeToRefs } from 'pinia'
import { useCartStore } from '../stores/cart'

export function useCartView() {
  const store = useCartStore()
  const { items, total } = storeToRefs(store)

  return {
    items: readonly(items),
    total: readonly(total),
    addItem: store.addItem, // the only way to actually change the cart
  }
}

AWrapping each storeToRefs()-derived ref in readonly() produces a version that can be read normally (reactively tracking the underlying store data), but any attempted write to it is blocked with a dev-mode warning — this gives a consuming component a live view of items/total without the ability to mutate them directly, funneling all changes through the explicitly exposed addItem action instead, enforcing a one-way "read this view, act through this action" contract

Breadonly() has no real effect on a ref that came from storeToRefs() — this code doesn't actually prevent mutation

Creadonly() disconnects the ref entirely from the store — items/total stop updating once wrapped, showing only a frozen snapshot from the moment useCartView() was called

DThis pattern requires the original store's state to also be wrapped in readonly() at the defineStore() level — otherwise readonly() here has no effect

Why does calling useCounterStore() inside this plain (non-component) script fail without the setActivePinia() call first?

javascript

import { createPinia, setActivePinia } from 'pinia'
import { useCounterStore } from './stores/counter'

const pinia = createPinia()
setActivePinia(pinia) // without this line, the next line throws

const store = useCounterStore()
console.log(store.count)

AInside a Vue component, useCounterStore() automatically finds the Pinia instance through Vue's own inject/provide mechanism (since app.use(pinia) provides it app-wide). Outside of a component's setup context — a plain script, a test file, a Node.js script — there's no component tree for inject to walk, so useCounterStore() has no way to find a Pinia instance unless one has been explicitly registered as the "currently active" one via setActivePinia() first

BsetActivePinia() is purely for TypeScript type-checking purposes — it has no runtime effect

CsetActivePinia() must be called once per individual store, immediately before every single useXStore() call throughout the entire codebase, including inside components

DcreatePinia() alone already activates the instance globally — setActivePinia() is a deprecated, no-longer-necessary extra step

Answer all 10 questions (7 more), see explanations for every answer, and track your score.