Request Races & Cancellation

## The problem both timers solve A text field emits one input event per keystroke. If every event starts a request, a ten-character query starts ten requests. Most of them answer a query the user never meant to ask, and because they all write into the same place they create a race over which response ends up on screen. **Debouncing** and **throttling** both cut the number of requests that start. They are different rules and they are not interchangeable. ## What a debounce does A debounce waits for silence. Each event resets one pending timer, and the work runs only when the timer expires with no further event — the **trailing edge** of a burst. - While the user types quickly, nothing starts at all. - One request starts once the user pauses for the chosen interval. - A keystroke during the wait replaces the pending run, so only the latest value survives. - A leading-edge variant fires on the first event and suppresses the rest of the burst. That suits an action that must feel instant, such as guarding a repeatedly clicked trigger; it is rarely what a search field wants. ## What a throttle does A throttle enforces a maximum rate. While events keep arriving, the work runs at most once per interval: the first event fires, later events inside the window are dropped or collapsed into a single run at the window's end. - Work happens *during* the burst, at a steady cadence. - The user sees sampled intermediate states rather than only the settled one. - The number of runs grows with how long the burst lasts, not with how dense it is. ## Choosing between them | | Debounce | Throttle | |---|---|---| | Fires | after the burst stops | during the burst, at a fixed rate | | Runs per burst | one, on the trailing edge | one per interval | | Intermediate values | discarded | sampled | | Fits | input whose only meaningful value is the settled one | a stream whose intermediate values are meaningful | | Typical use | search field, validation while typing, saving a draft | pointer movement, scroll position, resize-driven layout | The deciding question is simple: **does an intermediate value deserve a request?** For a search field the answer is no, so debounce. For a map that reloads markers while the viewport is dragged, the intermediate viewports are exactly what the user is looking at, so throttle. ## What a timer does not fix This is the part interviewers probe, because candidates routinely stop one step early. A timer changes **how many** requests start. It says nothing about **which response is allowed to reach the tree**. 1. Two debounced requests can still overlap: the user pauses, a request starts, the user types again, a second starts, and the first answers second. Without a latest-wins rule — tag each request and ignore anything that is not the newest, or cancel the superseded one — the older response overwrites the newer data. 2. A throttle guarantees overlap by design, since it deliberately keeps firing while an earlier run may still be pending. 3. A longer delay lowers the probability of a stale overwrite without removing it. Correctness that depends on timing is not correctness. So the honest answer pairs the two mechanisms: a timer for **volume**, and a latest-wins rule for **ordering**, plus cancellation of superseded work when letting it finish costs something worth saving. ## Practical details - **Pick the interval from human behaviour.** Roughly 150-300 ms of quiet reads as responsive for a search field; much beyond half a second and the field feels dead. Measure with real typists instead of arguing about it. - **The timer belongs to whatever owns the input.** When that instance is destroyed, the pending timer must be cleared, or it wakes up later and starts a request for a screen nobody is looking at. - **Debounce the request, never the displayed value.** The field must echo every keystroke immediately; delaying the rendered text makes the input feel broken. - **A trailing run must carry the latest argument.** A debounce that captured the first event's value and fires with it defeats its own purpose, so capture the value at fire time or overwrite the captured value on every event. - **Where the timer lives differs by reactivity model:** a runtime that re-runs the whole component function on every state write will recreate a naively declared timer on each pass unless it is held across passes; a runtime with fine-grained tracking re-runs only the reacting piece and keeps it naturally; a compile-time runtime can hide the difference. The rule that survives all three is the same — one long-lived timer per input, created once and cleared on teardown.