How would you cache data between a list and detail view?
Splitting server and client state, sharing cache from list to detail.
Use nested keys so detail reads from list cache with staleTime to skip refetches.
What's really being asked
Your understanding of the difference between server state and client state, and whether you can design a cache that shares data across routes without manual synchronization. The interviewer cares if you know when to use a dedicated data-fetching library over a general store, and whether you understand cache key hierarchies, staleTime, and background refetching.
The full answer
First, select a server-state library such as TanStack Query, SWR, or Apollo Client instead of using Redux or Pinia as a cache. Second, design hierarchical query keys so the list query and detail query relate to each other; for example, the list might use projects and the detail uses projects with an id. This allows the detail page to pull placeholder data from the list cache or from a normalized entity map. Third, configure staleTime to at least a few minutes so back-navigation does not refetch, while keeping background refetch enabled so out-of-date data updates silently. Fourth, mention normalization if the list and detail return different field depths, because storing entities by ID prevents duplication and keeps both views consistent.
The mistakes people make
Storing API responses in a global client store without deduplication, TTL, or normalization is a strong red flag. Another mistake is fetching on every route entry because you assume the user needs the absolute latest data; this misses the stale-while-revalidate trade-off. Hand-rolling your own cache expiration or request deduplication is also a warning sign that you are solving a problem that libraries already handle.
What usually comes next
Expect questions about how to update the list cache after a mutation on the detail page, or how to handle partial data when the list returns only summary fields. The interviewer might also ask how you would prefetch detail data on hover or during list rendering to make navigation feel instant.
A concrete example
Imagine a project management app with a list of tickets and a ticket detail page. You set up TanStack Query with a query key of tickets for the list and tickets with the ticket id for the detail. When the user clicks into a ticket, the detail hook reads the existing object from the list cache as placeholder data while the full detail query fetches in the background. You set staleTime to five minutes and cacheTime to ten minutes. When the user clicks back, the list renders instantly from cache and no network request fires because the data is still fresh. If a teammate updates a ticket elsewhere, the next window focus event triggers a silent background refetch so the UI stays current without blocking navigation.
Interview question
When configuring a server-state library to share cache between a list and detail view, which strategy best avoids refetching on back-navigation while keeping data updated?
- a.Store the list response in a global client state library like Redux and manually sync the detail view from that store.
- b.Implement a custom in-memory cache with manual TTL and deduplication logic shared between the two routes.
- c.Use nested query keys so the detail pulls from the list cache, set staleTime to a few minutes, and keep background refetch enabled.Correct
- d.Set staleTime to zero so both views always fetch the latest data from the server on every navigation.
Why? this is the answer
Nested query keys let the detail view reuse list cache as placeholder data, and a non-zero staleTime prevents refetching on back-navigation while background refetching preserves freshness. Using a general client store like Redux is a red flag because it lacks built-in deduplication, TTL, and normalization for server state.
Just read this? Test yourself on what you have been reading.
Read the original → tanstack.com
- #caching
- #state-management
- #tanstack-query
- #server-state
- #frontend-architecture
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on caching — each one lists the topics its interview covers.
See open roles