How would you cache data between a list and detail view?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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.

ONE 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.

Source: tanstack.com