The React counter that sticks at 1, and why no dependency array will fix it

A walkthrough published on dev.to reopens the most familiar failure in React code: a counter wired up with `useEffect`, an empty dependency array and `setInterval(() => setCount(count + 1), 1000)` renders 0, then 1, and then sits at 1 forever ^[1]. It matters because the two fixes that surface first either wreck the timing or narrow what the callback is allowed to read ^[3][4].

The mechanism is not subtle. The interval callback was created during the first render, when `count` was 0, and an empty dependency array guarantees it never sees another render, so `setCount(0 + 1)` fires every second and changes nothing ^[2]. At a one second delay that is roughly 3,600 state updates an hour, every one of them setting `count` to 1 ^[1]. The post's author calls it the single most searched React timer bug [cA].

Fix one is to add `count` to the effect's dependencies. The reads become correct and the timer becomes garbage: it is torn down and re-created every second, the timing resets on each change, and with a fast-changing dependency the tick may never fire at all ^[3]. Fix two, the functional updater, holds up until the callback needs anything other than the previous count ^[4]. Both are attempts to negotiate with a mismatch that does not negotiate. `setInterval` is imperative and lives outside React's render cycle, while everything it wants to read lives inside it ^[5].

Dan Abramov's 2019 essay "Making setInterval Declarative with React Hooks" is where the actual answer comes from: keep the latest callback in a ref, and never restart the timer just because the component re-rendered ^[6]. The hand-rolled version is about a dozen lines. A `savedCallback` ref, a `useLayoutEffect` keyed on the callback that assigns the freshest closure into it, and a `useEffect` keyed only on `delay` that bails out when `delay` is `null` and otherwise creates `setInterval(() => savedCallback.current(), delay)` with a `clearInterval` cleanup ^[7].

Two consequences fall out of that shape, and they are the reason to prefer it. Changing the callback never restarts the timer, so inline arrow functions and direct state reads are both fine and the interval keeps its rhythm ^[9]. Changing `delay` does restart it, because `delay` is the only dependency: 5000 to 1000 clears the old timer and starts a new one, which resets the phase so the next tick lands a full delay after the change committed ^[10]. That is correct for backoff and mildly surprising if you expected the in-flight tick to finish ^[10].

The write-up frames three distinct problems the pattern absorbs: stale closures, restart-on-render, and lifecycle ^[14]. `setInterval` holds one function reference for its whole life, closed over one render's props and state, and every later render mints a closure the running timer never sees ^[15]. Lifecycle is the one that quietly grows: clear on unmount, clear again on StrictMode's development remount, and pausing turns into a small state machine of extra state, an `if` around `setInterval`, and dependencies that now include the pause flag ^[16].

`useInterval` from `@reactuses/core` packages the same core, using `useLatest` for the ref, and adds the parts a real app needs ^[8][13]. Signature is `useInterval(callback, delay, options?)`, delay in milliseconds or `null` to pause, returning `{ isActive, pause, resume }` ^[11]. Swap it in and the callback reads props and state directly, the timer is created once and cleared on unmount, and there is no dependency array to get wrong ^[12].

What to watch: the `delay` phase reset, since any dynamic polling interval will silently reschedule from the commit moment ^[10]. The same post goes on to cover two pause strategies, dynamic intervals, the background-tab problem and when a different timer hook is the better choice ^[17], and background throttling is the constraint no ref pattern removes.