Where Data Lives: Frontend Data-Fetching & State Architecture

12 questions

The biggest architectural decisions in a modern frontend are about where data lives and when it's fetched. Start by separating server state (an async cache of data you don't own) from client state, then reason through normalized vs. document caches, request deduplication, optimistic updates and rollback, request waterfalls vs. parallel fetching, prefetch, staleTime tuning, and how Suspense reshapes component design. Aimed at the React/TanStack Query stack where these are daily decisions.

Start

Questions

Not answered. What really separates server state from client state?
Not answered. Which of these are client state?
Not answered. With default TanStack Query, why does the roster still show the old name?
Not answered. How many network requests does TanStack Query fire?
Not answered. Why cancel queries before an optimistic write?
Not answered. Which statements correctly describe the cache-driven optimistic-update pattern in useMutation?
Not answered. What makes this loader slow, and how do you fix it?
Not answered. Which techniques genuinely help eliminate request waterfalls?
Not answered. What does this prefetchQuery on hover accomplish?
Not answered. What's the idiomatic fix for refetching data that never changes?
Not answered. How does switching to useSuspenseQuery change the component's design?
Not answered. Which useMutation lifecycle callback runs before the mutation function?