Time-Based Throttling

## Two ways to thin a busy stream Keystrokes and scroll events arrive far faster than an application wants to act on them. RxJS 7.8 offers time-based operators that let only some of those values through. The two most asked about are `debounceTime` and `throttleTime`, and they answer different questions: - **`debounceTime(dueTime)`** asks: *has the stream gone quiet?* It emits only after `dueTime` milliseconds pass with **no new value**, and what it emits is the **latest** value. - **`throttleTime(duration)`** asks: *may I emit yet?* It emits a value, then **ignores** the source for `duration` milliseconds, then is ready again. Both take an optional scheduler, `asyncScheduler` by default, and both keep their state per subscription. ## Side by side | | `debounceTime(1000)` | `throttleTime(1000)` (default config) | |---|---|---| | first value of a burst | held | emitted immediately | | values during the burst | each replaces the held value and restarts the timer | ignored while the window is open | | when it emits | 1000 ms after the last value | at most once per 1000 ms window, at its start | | which value | the last one before the pause | the first one of each window | | continuous activity | emits **nothing** until it stops | emits steadily | | source completes with a held value | emits it at once, then completes | the ignored values are gone | ## Autosave while typing Autosave wants one request per pause, carrying the latest draft: ```ts draft$.pipe(debounceTime(1000)) ``` 1. The user types `h`, `he`, `hel`… — each value resets the one-second timer. 2. The user stops for a second — `debounceTime` emits `hello`, the current draft. 3. The save runs once instead of once per keystroke. Throttling here would save the *first* keystroke of each window (`h`) and, with the default config, drop the rest — the saved draft would lag behind what the user typed. The same reasoning applies to a search box: debounce the input so the query runs once the user pauses. Cancelling a request that is already in flight when a newer query arrives is a separate job, done by a flattening operator. ## Scroll-position tracker A tracker that updates a progress bar or a "back to top" button wants values **while** the user scrolls: - `debounceTime(100)` would update only after scrolling stops, so the bar freezes during a long scroll; - `throttleTime(100)` updates at most ten times a second throughout the scroll. With its default `{ leading: true, trailing: false }`, however, `throttleTime` emits the position at the **start** of each window and drops everything else. If the scroll ends in the middle of a window, the final position never arrives. The fixes are to enable the trailing edge or use `auditTime`, which emits the latest value at the end of each window. ## Choosing the durations The numbers are product decisions, not constants: | use case | operator | typical range | what a bad value feels like | |---|---|---|---| | autosave | `debounceTime` | 500–2000 ms | too short: a request per word; too long: edits at risk | | search input | `debounceTime` | 200–400 ms | too long: the box feels sluggish | | scroll tracker | `throttleTime` or `auditTime` | 50–150 ms | too long: the indicator visibly jumps | Measure the cost of the downstream work: if each emission triggers a request, the operator is also a rate limit on the server. ## Common mistakes - Assuming `debounceTime` emits "every N ms" — it emits only after silence, so a user who never pauses never triggers it. - Assuming `throttleTime` emits the latest value by default — it emits the first one. - Picking `debounceTime` for a progress indicator and wondering why it lags a full scroll behind. - Using a very long debounce for autosave: the longer the quiet period, the more edits are at risk if the stream is torn down before the timer fires. In an Angular component, the usual sources are a form control's `valueChanges` for the draft and `fromEvent(window, 'scroll')` for the tracker; the operators behave the same regardless of where the values come from.