DEV Community: Tarun Sharma

React Query's staleTime vs gcTime: the difference that actually bites people

Tarun Sharma — Wed, 16 Sep 2026 18:52:22 +0000

You set up React Query, wire up a useQuery, and everything works. Then a teammate asks: "why did this refetch when I switched tabs and came back, even though nothing changed?" and a week later someone else asks the opposite: "why is this data still showing after the component unmounted and remounted five minutes later?"

Both questions come from the same confusion: mixing up staleTime and gcTime (called cacheTime before React Query v5).

What each one actually controls

staleTime answers: "how long is this data considered fresh, so React Query doesn't bother refetching it automatically?"

gcTime answers a completely different question: "how long should this data stay in memory after nothing is using it anymore, before React Query throws it away?"

They're not two settings for the same knob. One is about refetch behavior while something is actively subscribed to the query. The other is about cleanup after everything unsubscribes.

The default that surprises people

useQuery({
  queryKey: ['user', id],
  queryFn: () => fetchUser(id),
})

With no options, staleTime defaults to 0. That means the instant the query resolves, it's already stale. It won't show a loading spinner again because you still have cached data to render, but React Query will quietly refetch in the background on the next relevant trigger, window focus, remount, reconnect. That's the tab-switch refetch people report as a bug. It isn't one. It's the default working as designed for data that changes outside your app's control.

gcTime defaults to 5 minutes. That's why data can outlive the component that fetched it. Unmount the component, and React Query doesn't delete the cache entry immediately, it waits, because you might navigate back within a few minutes and it can skip the network round trip entirely.

Where this actually bites

A case that comes up a lot: a details page fetches with staleTime: Infinity because the data rarely changes, then the user navigates away and back within a minute, expecting a fresh value because something changed server-side. With staleTime: Infinity, React Query will never consider it stale on its own, no refetch happens, no matter how long you wait. That's not a bug in the library, it's the setting doing exactly what it says. If you want "cache aggressively but still refetch after a while," you want a finite staleTime, not Infinity.

The opposite bites people building anything sensitive, carts, live counts, permissions. Setting a long gcTime doesn't make data go stale slower, it only controls how long unused data survives in memory. If you actually want fewer background refetches, that's staleTime's job, not gcTime's.

A mental model that holds up

Think of staleTime as an expiry date on food you're currently eating, and gcTime as how long you'll keep leftovers in the fridge after you're done. Extending the expiry date doesn't change how long the leftovers last once you stop eating, and keeping leftovers around longer doesn't make the food fresher while you're actively eating it. Same query, two independent lifecycles.

useQuery({
  queryKey: ['user', id],
  queryFn: () => fetchUser(id),
  staleTime: 60 * 1000,      // fresh for 1 minute, no background refetch during that window
  gcTime: 10 * 60 * 1000,    // keep it around 10 minutes after nothing subscribes
})

Once you separate the two questions, "is this refetching too much" and "is this staying in memory too long or too short", picking values stops being guesswork.

Have you shipped a bug that turned out to be one of these two settings confused for the other? What was the giveaway that finally pointed you at the right one?

5 more React interview questions I'd actually ask (and how I'd answer them)

Tarun Sharma — Wed, 09 Sep 2026 15:36:44 +0000

The first version of this list did well enough that people asked for more, so here are five more React questions I actually reach for in interviews. Same idea as before: none of these are trivia, they all come from bugs I have watched people ship.

1. Why can using an array index as a `key` break things?

Most people know "don't use index as key" as a rule without knowing what it protects against. The key tells React which element in the new list matches which element in the old list. If you key by index and the list reorders, index 0 is still index 0, so React thinks nothing moved. It keeps the old component instances in place and just updates their props.

For a list of plain text that is fine. The moment a row holds state that React owns, it breaks: an uncontrolled input keeps the value that belonged to the row that used to be there, focus stays on the wrong row, a half-finished CSS transition plays on the wrong element. Prepending an item is the classic trigger, because every index shifts by one and React re-renders every single row instead of mounting one.

Use a stable id from the data. If you genuinely have no id and the list never reorders, index is acceptable, but say so out loud so the next person knows it was a choice.

2. What is a stale closure and where does it bite in React?

A closure captures the variables that were in scope when the function was created, not when it runs. In React your function components re-run on every render, so each render has its own copy of props and state. A callback created on render 1 closes over render 1's state forever.

useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1); // count is always 0 here
  }, 1000);
  return () => clearInterval(id);
}, []); // empty deps, so this effect only ever saw the first render

The interval callback was created once, when count was 0, and it keeps reading that 0. The fixes are the functional updater setCount(c => c + 1), or putting count in the deps and letting the effect re-subscribe, or a ref if you need the latest value without re-running the effect. The same trap shows up in event handlers passed to addEventListener and in setTimeout callbacks inside effects.

3. Why can't you call a hook inside a condition?

React does not pass hooks a name or a key. It relies purely on call order. On every render, the first useState it sees maps to the first state slot, the second to the second, and so on. If a hook call is behind an if, the order changes between renders, and now useState number 2 is reading the slot that belonged to a useEffect.

That is the whole reason for the rules of hooks. It is not style, it is that the mechanism has no other way to line up "this call" with "that piece of state." Once people see it as an array indexed by call count, the lint rule stops feeling arbitrary.

4. Here is a component wrapped in `React.memo` that still re-renders every time. Why?

React.memo does a shallow compare of props. If the parent passes an object or array or function literal as a prop, that literal is a brand new reference on every render, so the shallow compare always says "different," and memo does nothing.

<Child style={{ margin: 8 }} onClick={() => doThing(id)} />

Both style and onClick are recreated each render. To make the memo actually hold you have to stabilise those references with useMemo and useCallback, or lift the object out of the component if it never changes, or restructure so the child does not need them. A lot of "I added memo and nothing got faster" reports are exactly this.

5. Will an error boundary catch an error thrown in an `onClick` handler?

No. Error boundaries catch errors during rendering, in lifecycle methods, and in the constructors of the tree below them. They do not catch errors in event handlers, in async code, in setTimeout, or in the boundary's own code. Event handlers run outside the render cycle, so React lets the error propagate to the normal browser error handling instead.

If you want handler errors to show a fallback, you catch them yourself and put the failure into state, then render based on that state. Knowing this line matters because people wire up a boundary, test it by throwing in a click handler, see nothing happen, and conclude the boundary is broken.

If your answer to any of these was "it's just best practice," that is usually the sign there is a mechanism underneath worth understanding. Happy to hear which ones you would swap out.

useMemo and useCallback: 5 things that actually trip people up

Tarun Sharma — Tue, 18 Aug 2026 12:47:54 +0000

Both of these get memorized as syntax pretty fast. What doesn't get memorized is what they're actually doing under the hood, and that's where the bugs show up. Here's the stuff that actually trips people up once you go past "wrap it in useMemo I guess."

1. They solve different problems, not the same one

useMemo caches a value. useCallback caches a function reference. People treat them like interchangeable "make it faster" hooks, but useCallback(fn, deps) is really just useMemo(() => fn, deps) under the hood, it just hands you back the function itself instead of calling it for you.

2. Neither one makes your code faster by default

Wrapping something in useMemo has a cost too, it runs the dependency comparison on every render. If the calculation inside is cheap, you're paying more than you save. Reach for these when the calculation is genuinely expensive, or when the value needs to keep the same reference across renders (see #3), not as a reflex on every derived value.

3. The real reason you need useCallback: keeping props stable for React.memo

If you pass a normal inline function as a prop to a memoized child, that child re-renders anyway, because the function is a new reference every single render. useCallback is what actually keeps that reference stable across renders so React.memo's shallow comparison has something to bail out on. Without it, memo is comparing a new function to another new function every time and always finding them "different."

4. The dependency array lies just as easily here as with useEffect

Same stale closure trap you'd hit with useEffect. If you memoize a function with useCallback(fn, []) and fn reads a prop or state value from outside, you get a function frozen with whatever that value was on the first render. The fix is the same one as always: put it in the deps array, don't fight the linter into silence.

5. Object and array literals as deps break memoization silently

useMemo(() => doSomething(config), [config]) looks safe until config is { foo: bar } created inline on every render, in which case the dependency is a new reference every time and the memo never actually hits, it recalculates every render while looking like it's working. Move the object outside the render, or memoize it too.

Curious what the actual useMemo or useCallback bug was that got you. Drop it below, would love to hear it.

5 React interview questions I'd actually ask (and how I'd answer them)

Tarun Sharma — Fri, 14 Aug 2026 08:26:33 +0000

Most "React interview questions" lists online are either trivia (define useEffect) or so advanced they're not useful below 3-4 years of experience. Here are 5 I think are actually worth knowing, with the answer I'd give if asked.

1. What does this log, and why?

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i));
}

It logs 3, 3, 3. var gives the whole loop one shared variable, so by the time the callbacks run, the loop has already finished and i is 3. Swap var for let and it logs 0, 1, 2, let creates a fresh binding for every iteration, so each callback closes over its own copy.

2. Why doesn't an empty dependency array guarantee no stale-closure bugs?

An effect with [] only runs once, but any function or state it references from the render it was created in is frozen at that value forever, that's a stale closure. It's the same mechanism as question 1, just applied to a React render instead of a loop iteration.

3. What's the actual difference between useMemo and useCallback?

useCallback(fn, deps) is just useMemo(() => fn, deps). One memoizes a value, the other memoizes a function reference. People treat them as separate concepts when one is a special case of the other.

4. Why can a sibling component re-render even though its own props didn't change?

Because React re-renders every child of a component that re-renders, by default, regardless of whether that specific child's props changed. React.memo is what actually stops it, re-rendering isn't opt-out at the parent level, it's opt-in per child.

5. What does the virtual DOM actually skip?

It skips DOM writes, not DOM reads or re-renders. React still runs your component function and builds a new tree every render; the virtual DOM diff is what decides which actual DOM mutations are necessary, which are usually the expensive part.

What would you add to this list?