Polling and Refetching Strategies

The plain-language idea

An initial fetch answers "what's the data right now." Staying fresh over time is a separate concern, and there are three concrete, commonly-used patterns for it:

• Fixed-interval polling — refetch on a timer (setInterval, or a data-fetching library's built-in polling option). Simple and predictable, but it burns requests even when nothing has changed, and it needs a real cleanup step or the interval keeps running after the component that started it is gone.
• Refetch on window focus — only refetch when the user's browser tab regains focus. Much cheaper than constant polling, and a good fit for data that only needs to be fresh when someone is actually looking at it — a dashboard doesn't need to poll every 5 seconds while its tab is in the background.
• Refetch on reconnect — detect the browser regaining network connectivity after a drop and refetch immediately, rather than continuing to poll uselessly while offline or waiting out the rest of a scheduled interval after coming back online.

These aren't mutually exclusive — a real app commonly combines refetch-on-focus and refetch-on-reconnect as cheap always-on defaults, and reserves fixed-interval polling for the specific data that genuinely needs to update without any user interaction at all (a live order status, a build's progress).

See it in a real thing: polling that avoids the stale-closure bug

function useOrderStatus(orderId: string) {
  const [status, setStatus] = useState<string | null>(null);
  const fetchStatus = useRef(async () => {});

  // Keep the ref pointing at a function that closes over the *current* orderId.
  fetchStatus.current = async () => {
    const res = await api.getOrderStatus(orderId);
    setStatus(res.status);
  };

  useEffect(() => {
    const id = setInterval(() => {
      fetchStatus.current(); // always calls the latest version, never a stale one
    }, 5000);

    return () => clearInterval(id); // real cleanup — no leaked interval on unmount
  }, []); // empty deps: the interval itself is created once, the ref keeps it current

  return status;
}

What people usually miss

Watch out

• Forgetting clearInterval in the cleanup function is a real, common memory leak. The interval keeps firing after the component unmounts, calling setState on an unmounted component and doing pointless work indefinitely.
• A stale closure over props/state is the other classic setInterval bug, distinct from the leak above — the interval runs fine and never leaks, it just keeps acting on old data because the callback it was given closed over values from when the interval was first created.
• Fixed-interval polling wastes requests by design — most polls return "nothing changed," and that's an accepted cost of the simplicity, not a bug, but it's worth naming explicitly when choosing this pattern over the cheaper alternatives.
• Refetch-on-focus and refetch-on-reconnect aren't polling substitutes for genuinely real-time needs. A user staring at one tab the whole time never triggers a focus refetch — they're a cheap freshness heuristic for data that's fine going stale while unattended, not a guarantee of freshness while attended.
• Combining strategies is normal, not redundant. Polling every 30 seconds AND refetching immediately on focus/reconnect covers both "give up eventually" and "catch up the moment attention or connectivity returns," which neither one alone does as well.

Why this matters in interviews

"How would you keep this dashboard's data reasonably fresh without hammering the server?" is a real question, and naming all three patterns — plus the specific setInterval cleanup and stale-closure gotchas — shows you've actually debugged a leaking or stuck polling loop before, not just read the word "polling" in a doc.