reactive.how 2.0-alpha Menu

debounceTime vs throttleTime

If your stream is created from key presses or mouse movements, you’ll likely deal with bursts of events. But you can’t react to every single event, as it would overload the CPU or flood the servers with too many requests.

❚ debounceTime rate-limits events, based on an “emission silence” window of time. ❚ throttleTime doesn’t delay events.

They both accept a time period argument, such as 500 milliseconds.

debounceTime

This is how ❚ debounceTime operates:

  • Whenever an event is emitted, the period of silence measured restarts from zero
  • The card waits for a “due time” silence and then emits the latest value of the input stream
  • As a result, it returns a new stream of debounced events

throttleTime

This is how ❚ throttleTime operates:

  • It starts by emitting the first event of the input stream
  • Then, it limits the rate of events to at most one per time period
  • As a result, it returns a new stream of “throttled” events

See also


debounceTime vs delay


scan vs reduce


zip vs combineLatest


The JavaScript pipeline operator proposal

💌 I create something new each week!
Learn Reactive Programming and stay tuned.

Occasional updates, plus:

Cédric Soulas - Freelance Developer Advocate. Learn more.

Follow 👨‍💻 Hire me

News

@CedricSoulas