Demo:  throttleTime

After every emit, the time-interval filter throttleTime, discards the source items for the specified throttletime duration.

throttleTime(throttleTimeInMilliseconds)

//Delays each item by v*100 milliseconds
const source = of(2,8,15,25,4,45,5,6)
        .pipe(concatMap(v=>of(v).pipe(delay(100*v))));

//After every emit, ignore the inputs for next 2 secs
const timeIntervalFilter = throttleTime(2000);

const output = source.pipe(timeIntervalFilter).subscribe(v=>console.log(v))
What is happening ?

After every emit, the time-interval filter throttleTime:

  • discards the source items for the specified throttletime duration.

Let's understand how it works with the demo. Let's start with the first item 2 from the source.

  • As soon as the value 2 arrives the "throttle Time" filter immediately emits it.
  • It, also, starts the specified throttle time interval of 2 seconds where it discards incoming source inputs.
  • Thus, it discards 8 as it falls within the throttle time intervals.
  • 15 comes after 8+15=23 or 2.3 seconds after 2, falling beyond the first throttle time interval. Now, the filter starts the throttle time cycle again for 15.
  • But, discards nothing as the next value arrives only after 2.5 seconds. Again, the filter starts it's next cycle with 25, discarding 4. Importantly, the last throttle time cycle starts with 45.
  • 2 source items 5 and 6 arrives within this cycle, hence the filter discards both of them. Now analyzing the output here, since the throttleTime emits the first value without any delay:
  • It's a good choice, if all our source items are similar and we are just limiting the rate.
  • But, in case the latest value is important to us, then this filter is not the right choice.
  • The "audit Time" or the "debounce Time" could be the right alternatives here.
More on : throttleTime

A close counterpart to throttleTime is auditTime.

  • Whereas throttleTime discards the inputs for a specified interval, after every emit.
  • auditTime instead of emiting the first input, waits for the interval to be over to emits it's latest value.

The difference of emitting at the begining and the end of intervals makes each of them suitable for separate scenarios. For instance,

  • Proactive Sampling, to Rate Limit Similar Inputs

    • throttleTime is suitable to limit the rate of inputs, with no delay at the first emit.
    • It is suitable for inputs such as clicks, which are similar and do not represent a change. In case of changing values, the throttleTime is likely to miss out on the last changed value.

  • Delayed Sampling, to Capture the Changes

    • auditTime is suitable for auto-complete or typeahead cases, where the delayed sampling, at the end of the interval, helps us take a useful change in the user input.

Usages

1. Proactive Sampling, to Rate Limit Similar Inputs


Let's say we want the user to click at most once every second.

throttleTime(1000) will help us discard new clicks for a second after every click.

 import { fromEvent, throttleTime } from 'rxjs';

 const clicks = fromEvent(document, 'click');
 const result = clicks.pipe(throttleTime(1000));

 result.subscribe(x => console.log(x));

For cases where the newer inputs represent a change, throttleTime wont be suitable as it is likely to missout the latest changes.