Eye Training · Timers

Every timer needs three answers: what clears it, what if the work is slow, and what if it runs late.

Part 2 · Surface 13. Bug counts are hidden and some snippets are clean. See Start Here for how to use these drills.

J · The basics

M · Three years in, these should jump out

S · Where seniors stand out

What your eye checks

Whenever you see setTimeout or setInterval, ask:

1. What clears it? Every interval needs a clearInterval on the path that ends it: unmount, close, stop, done, and failure.
2. What if the work takes longer than the interval? setInterval doesn't wait for async work; chained setTimeout does.
3. Is it passed a function, or the result of calling one?
4. What does the callback capture? var in a loop, this in a plain function, stale variables.
5. What if it runs late? Timers are a minimum delay, not a promise. Background tabs throttle them, and busy event loops delay them. Compute from a deadline, never by counting ticks.
6. Can two callers share one timer by accident, or can one caller orphan a timer by overwriting its id?
7. What if the process restarts, or there are several instances? In-memory timers are lost on restart and are per-instance. Anything that must happen belongs in a database or job queue.
8. Does it hold the process open? An active timer keeps Node alive; a CLI or a test needs it cleared or unrefed.

Tells

Go deeper

• The Event Loop Under Pressure: why timers run late, with a simulation
• Controlling Concurrency: Part 10 builds debounce and throttle; Cancellation and Cleanup covers timeouts that don't cancel anything
• Previous surface: Promises and async/await · Next: Events, listeners and sockets