Store Composition — Series 2

Preview — 3 of 10 questions

Why is the function form of $patch recommended for this array mutation, instead of writing it as a plain object?

javascript

const store = useCartStore()

// Function form
store.$patch((state) => {
  state.items.push({ id: 3, name: 'Widget' })
  state.lastUpdated = Date.now()
})

A$patch((state) => {...}) receives the actual store state directly, letting you run arbitrary mutation logic against it — including operations like .push() that an object-form $patch({...}) genuinely can't express (an object patch can only describe direct property replacements, not "append to this array"). It also batches every mutation performed inside the callback into a single subscription notification/devtools entry, rather than one per individual change

BThe function form and an equivalent object form behave identically — this is purely a stylistic preference with no practical difference

CThe function form only works for adding new properties to state — it can't be used to modify existing ones

D$patch with a function requires async/await, since the callback always runs asynchronously

What's the practical difference between these two ways of reacting to store changes?

javascript

import { watch } from 'vue'
import { storeToRefs } from 'pinia'

const store = useCartStore()
const { items } = storeToRefs(store)

// Option A: plain Vue watch
watch(items, (newItems) => {
  console.log('items changed (watch):', newItems.length)
}, { deep: true })

// Option B: Pinia's dedicated subscribe
store.$subscribe((mutation, state) => {
  console.log('items changed ($subscribe):', mutation.type, state.items.length)
})

APlain watch() on a storeToRefs'd property works like any other Vue watcher, reacting to changes in that specific ref; $subscribe() is store-specific and fires for any mutation to the store's state (not just one particular property), and its callback additionally receives structured mutation metadata (like mutation.type — 'direct', 'patch object', or 'patch function' — and, for direct/patch-object mutations, the actual changed keys) that plain watch() has no equivalent for

BThey're functionally identical — $subscribe is just Pinia's internal alias for watch(), with no behavioral differences

C$subscribe() only fires once, on the store's initial creation — it's not meant for ongoing change detection

Dwatch() cannot be used on storeToRefs()'d values at all — only $subscribe() works with Pinia stores

Why does this subscription keep firing even after MyComponent has unmounted?

javascript

<script setup>
import { useCartStore } from './stores/cart'

const store = useCartStore()

store.$subscribe(
  (mutation, state) => {
    sendAnalyticsEvent('cart_changed', state.items.length)
  },
  { detached: true }
)
</script>

ABy default, a $subscribe() call made inside a component's setup is automatically tied to that component's lifecycle and stops firing once the component unmounts (mirroring how watch/watchEffect created in setup are auto-cleaned-up). { detached: true } explicitly opts out of that automatic cleanup, keeping the subscription active for as long as the store itself exists — regardless of whether the component that originally created it is still mounted

B{ detached: true } has no real effect — this is a no-op option kept only for backward compatibility

C{ detached: true } makes the subscription fire only once, then automatically unsubscribe itself

D{ detached: true } moves the subscription's execution to a Web Worker, detached from the main thread

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