Differentiate client state from server state and their tools

WHAT THIS TESTS: Whether you understand that state is not monolithic. Interviewers want to see if you distinguish between data you own versus data you merely cache, and if you know why mixing these concerns in one store leads to bugs and boilerplate.

A GOOD ANSWER COVERS: First, define the divide. Client state is local, synchronous, and deterministic; examples include UI themes, modal visibility, and form inputs before submission. Server state is remote, asynchronous, and shared; it can be stale, updated by other users, and must be fetched over the network. Second, explain the tooling split. Pinia is ideal for client state because it offers reactive mutations, devtools integration, and simple module composition without opinionated data-fetching overhead. Vue Query is purpose-built for server state because it provides caching, deduplication, background refetching, garbage collection, and optimistic updates out of the box. Third, discuss trade-offs. Using Pinia for server state means manually writing fetch logic, cache keys, invalidation, and race-condition guards, which is error-prone. Using Vue Query for client state forces async patterns onto synchronous UI concerns and adds unnecessary cache complexity. Fourth, mention the hybrid reality. Most production apps use both: Pinia for auth tokens or sidebar collapse state, and Vue Query for lists and detail views, with clear boundaries between them.

COMMON WRONG ANSWERS: Claiming that Vue Query fully replaces Pinia or any client state manager. The TanStack docs explicitly state that global state managers are still needed for non-server-state concerns. Another red flag is arguing that Pinia is enough because you can store API responses in a store; this ignores the cost of reinventing stale-while-revalidate, deduping, and network error retry logic. A third mistake is framing the choice as purely about preference rather than lifecycle and ownership.

LIKELY FOLLOW-UPS: How do you keep Pinia and Vue Query in sync when a mutation changes both server data and local UI state? When would you prefetch in Vue Query versus hydrate from server state in Nuxt? How do you handle optimistic updates that also need to rollback local Pinia state on failure?

ONE CONCRETE EXAMPLE: Imagine an e-commerce dashboard. The selected date range and visible column preferences are client state stored in Pinia because they disappear when the user leaves the page and are never persisted to the database. The order list and revenue chart data are server state fetched by Vue Query, which caches the results for five minutes, refetches on window focus, and invalidates the cache when a new order is submitted through a mutation. If you stored the order list in Pinia, you would need to write custom logic to refetch it every time the user returns to the tab, whereas Vue Query handles that automatically.

Source: tanstack.com