The two-effect split is the heart of the pattern. The first effect keeps cbRef.current synced with the latest callback (so closures inside the parent component always see fresh state). The second effect creates the actual setInterval and depends only on delay, so changing the callback does NOT tear down and recreate the timer. Without this split, a counter that increments inside the callback would either hold stale state or restart on every render, both of which are common bugs in hand-rolled useInterval code.

Accepting delay = null as a sentinel for 'pause' keeps the API trivial to drive from React state: useInterval(tick, isRunning ? 1000 : null). The early return undefined skips the timer setup entirely, and switching from a number to null tears down the existing one via the effect cleanup. This is the exact shape Dan Abramov published, and it cleanly handles the start / pause / resume cycles that real apps need (poll while a tab is visible, stop on pause).

The same ref-plus-effect pattern works for one-shot timers. The differences are tiny: setTimeout instead of setInterval, and the cleanup runs clearTimeout. This shape is useful for delayed reveals (toasts that auto-dismiss after a few seconds), debounced submits where you want to abort the pending submit on prop change, and any animation that needs to fire after a delay. As before, passing null parks the timer indefinitely so it never fires until the delay becomes a number.