Pinia Basics — Series 3

Preview — 3 of 10 questions

What does this do?

javascript

const cart = useCartStore()
cart.$patch({
  itemCount: 3,
  discount: 0.1,
})

A$patch merges the given object into the store's existing state — only itemCount and discount are updated to the new values, while every other state field is left completely untouched. It's a convenient shorthand for updating several state fields in one call, equivalent to (but more concise than) setting each one individually

BIt replaces the entire store's state with exactly { itemCount: 3, discount: 0.1 }, discarding every other state field the store had

C$patch only works on getters, never on raw state fields

DThis throws unless every field of the store's state is included in the object passed to $patch

Why are Pinia stores conventionally named useCartStore, useAuthStore, and so on, rather than just cartStore or getCartStore?

javascript

export const useCartStore = defineStore('cart', { ... })

APinia's defineStore requires the returned variable name to start with use, or it throws a runtime error

BuseXStore is purely a stylistic choice with no connection to any broader convention — any name works identically

CIt follows the same use* naming convention Vue's own composables use, signaling "calling this returns reactive, composition-API-style state, and it should be called at the top level of setup() (or another composable) rather than conditionally" — even though a Pinia store instance can technically be safely used outside of a component's setup phase too (unlike a typical composable), the naming keeps stores visually consistent with the rest of a codebase's composable-style APIs

DThe use prefix is what makes Vue DevTools display the store in its Pinia inspector tab — omitting it hides the store from DevTools entirely

Given a store with state: () => ({ price: 100, quantity: 3 }), when is a getter actually needed instead of just reading a state field directly in a template?

javascript

// Option A: read state directly
{{ cart.price }} × {{ cart.quantity }}

// Option B: a getter
const totalPrice = computed(...) // inside the store: total: (state) => state.price * state.quantity

AA getter is required any time more than one state field needs to be read together, even without any actual computation

BThere's never a real distinction — getters and plain state fields behave identically in every situation, so which one to use is purely arbitrary

CA plain state field is fine (and simpler) when a template just needs the raw stored value as-is — a getter earns its place specifically when some derived value needs to be computed from one or more state fields (like total = price * quantity), since it gives that computation a name, caches the result until a dependency changes, and avoids repeating the same calculation inline in every template that needs it

DGetters can only be used for formatting strings (like currency), never for numeric calculations

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