The API Was Right. Why Did React Show the Wrong Tab?

Record the active tab, selected scope and resource displayed. Then inspect the request and its returned shape. If the network response already contains workout data, investigate the service or request construction. If the response contains meal plans but the UI shows workouts, move toward cache identity, selected arrays and component state.

This sounds obvious, but it prevents a common debugging loop: changing the renderer because it is the visible layer. A screen is the final symptom, not necessarily the source. The quickest investigation is often one that proves a layer innocent before editing it.

TanStack Query uses keys to identify cached data. Two requests that mean different things need identities that preserve the difference. A resource type, scope and relevant record identifier often belong in that key. Authentication and organisation changes may introduce additional boundaries that the application must handle deliberately.

A stale-time setting is not a substitute for correct identity. Fetching the wrong resource more frequently does not make it right. Similarly, increasing cache duration can make a successful demo feel faster while preserving the mix-up longer. Before tuning freshness, establish that the cache entry represents the intended data.

An independent JavaScript example demonstrates the risk: a query declares a specific key and then spreads a shared options object containing a generic key afterwards. Object property order means the later value replaces the earlier one. The visible code can look specific while the final options are not.

This is a teaching reproduction, not a claim that the current product still contains that exact object. Current source inspection shows distinct meal-plan configurations. Historical notes describe an override mechanism, but proving the original causal chain would require the matching old revision. Keeping that qualification matters more than making the post sound like a dramatic discovery.

const shared = { queryKey: ['workouts'] };
const wrong = { queryKey: ['meals'], ...shared };
// wrong.queryKey is ['workouts']

const freshness = { staleTime: 30_000 };
const right = { ...freshness, queryKey: ['meals', 'personal'] };

I prefer resource-specific options that do not carry an unrelated key. If a shared builder supplies keys, give it clear inputs and test its output. Place a deliberately chosen resource key where it cannot be accidentally replaced, rather than relying on every caller to remember a subtle spread convention.

For a fictional library screen, workout templates and meal templates can share retry or freshness defaults while keeping separate keys and fetchers. The shared abstraction should express what is common. It should not quietly decide which dataset a page means. A compact abstraction is not an improvement if its hidden behaviour makes the screen harder to debug.

After editing a meal template, invalidate or update the relevant meal resource and any list that contains it. Invalidating a workout prefix may be syntactically valid and have no useful effect. Updating a detail cache while leaving the list stale can also make navigation look inconsistent.

I would write down the resources affected by create, edit and delete. Then verify the list, detail and any derived count. The point is not to invalidate everything after every click. It is to make the relationship between a mutation and its visible consequences explicit enough to inspect and test.

An empty list can be the correct response for an account with no saved templates. Replacing it with another resource’s data to avoid a blank screen would manufacture content. The UI should distinguish an empty successful result, a failed load and an older cached result shown during a refresh.

The local component study accompanying this article uses fictional records and real website components. It shows separate resource labels, not a live production account. That gives a reader a useful visual explanation without implying that a screenshot is evidence of a particular customer’s data or a completed backend test.

Persisting a cache across reloads introduces another question: what happens when the signed-in account or organisation changes? Session storage is shorter-lived than local storage in typical browser use, but it is not an authorisation boundary. Same-origin scripts can still access it, and logout needs deliberate cleanup.

The server must enforce access regardless of what the cache holds. On the frontend, prevent one account’s cached state from appearing under another session and avoid persisting sensitive data without a clear reason. Short time-to-live values reduce some stale-state problems; they do not transform unsafe data handling into secure design.

Build a tiny case with two resource types, different returned shapes and explicit keys. Reproduce an options override and then remove it. Verify the initial load, rapid tab switching, background refresh and an edit followed by navigation. This is a meaningful test of behaviour rather than a snapshot of implementation syntax.

Changing a ternary into an equivalent if/else is not a cache fix. It can make a code path easier to read, but the causal explanation must still identify a changed value or dependency. That distinction is useful in AI-assisted development too: a plausible-looking patch is not evidence that the original problem was understood.

Should tab names always appear in keys? Only when they change the resource being requested. A purely visual tab over the same dataset may not need separate caching. Describe the data identity, not every incidental UI state.

Can stale data be useful? Yes, when it belongs to the correct resource and is clearly handled during refresh. Stale but relevant data is different from fresh data from the wrong account or resource.

What is the first thing to inspect? The final query options and the cache entry they address, alongside the actual network response. Debugging those together is usually more informative than guessing which component needs a new state variable.