Pinia Basics — Series 2

Preview — 3 of 10 questions

Why does count stay reactive here, when plain destructuring wouldn't work?

javascript

import { storeToRefs } from 'pinia'
import { useCounterStore } from './stores/counter'

const store = useCounterStore()
const { count } = storeToRefs(store)

console.log(count.value) // stays in sync as store.count changes

AstoreToRefs() converts each of the store's state/getter properties into its own individual ref, wired back to the live store — reading count.value (or using count directly in a template, auto-unwrapped) stays correctly reactive, unlike plain destructuring (const { count } = store), which copies out the current value at that instant and loses the connection entirely

BstoreToRefs() deep-clones the store's state into a new, independent reactive object

CstoreToRefs() only works inside <script setup> — it throws when called in a plain setup() function

DstoreToRefs() and plain destructuring behave identically — this code works only because count happens to be a primitive number

Why does this code call store.increment directly, instead of destructuring it through storeToRefs()?

javascript

import { storeToRefs } from 'pinia'
import { useCounterStore } from './stores/counter'

const store = useCounterStore()
const { count } = storeToRefs(store)   // state/getters go through storeToRefs
const { increment } = store             // actions are destructured directly

AstoreToRefs() specifically only converts state and getters into refs — it deliberately skips actions, since actions are just plain functions, not reactive data; a function reference doesn't need (or benefit from) being wrapped in a ref, and destructuring a function directly off the store works fine because functions aren't subject to the same "destructuring loses reactivity" problem values are

BThis is a bug — increment should also be passed through storeToRefs(), otherwise it won't work correctly when called

CActions can never be destructured under any circumstances — increment must always be called as store.increment()

DstoreToRefs() wraps everything, including actions, but calling a destructured action loses its this binding to the store, making this example broken

What happens if two different stores are both defined with the same id?

javascript

// stores/cart.js
export const useCartStore = defineStore('data', { state: () => ({ items: [] }) })

// stores/wishlist.js
export const useWishlistStore = defineStore('data', { state: () => ({ favorites: [] }) })

AThe id string passed to defineStore() is used as the store's unique key in Pinia's internal registry — two different defineStore() calls sharing the same id collide, and the second one effectively overwrites/reuses the first's registered store, producing confusing, incorrect behavior (state, getters, and actions from whichever definition "wins" internally) rather than two genuinely separate stores

BPinia automatically renames the second store's id to avoid the collision, appending a number ('data-2')

CThis throws a compile-time TypeScript error, but works fine in plain JavaScript

DPinia ignores the id argument entirely for uniqueness purposes — stores are actually keyed by their file path

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