We are going to talk about two other operators of DELAY, which are very useful for UI operations, especially for performance optimization.

Operators

debounce

Like buffer and bufferTime, Rx has debounce and debounceTime, one is an incoming observable and the other is an incoming millisecond. The most commonly used is debounceTime

var source = Rx.Observable.interval(300).take(5);
var example = source.debounceTime(1000);

example.subscribe({
    next: (value) = > { console.log(value); },
    error: (err) = > { console.log('Error: ' + err); },
    complete: (a)= > { console.log('complete'); }});/ / 4
// completeCopy the code

JSBin | JSFiddle

It just prints 4 and then it’s done, because Debounce runs by caching an element every time it receives an element, waiting for a certain amount of time, and then sending it out if no element has been received in that time. If a new element is received during that time, the cache element is released and timed again.

In our current example, we send a value every 300 milliseconds, but our debounceTime is 1000 milliseconds, which means that every time debounceounce receives an element, it will receive the next element and wait another 1000 milliseconds. This repeats until the fifth element is sent, observable completes, and debounce sends the element directly.

The Marble Diagram is shown below

source : --0--1--2--3--4|
        debounceTime(1000)
example: --------------4|Copy the code

Debounce will wait for a certain amount of time after receiving an element, which is really good for intermittent behavior, which is when it’s done in chunks, for example, to do Auto Complete, we have to type the search and it’s not always typed, it can wait until we’ve stopped for a short period of time before sending it out, I don’t send request every time I type!

As a simple example, suppose we want to automatically send user typed words to the back end

const searchInput = document.getElementById('searchInput');
const theRequestValue = document.getElementById('theRequestValue');

Rx.Observable.fromEvent(searchInput, 'input')
  .map(e= > e.target.value)
  .subscribe((value) = > {
    theRequestValue.textContent = value;
    // Send request here
  })Copy the code

If we use this code, we will send request every time we type, which will cause a lot of burden to the server when many people use it. In fact, we only need to send the last text that the user typed.

const searchInput = document.getElementById('searchInput');
const theRequestValue = document.getElementById('theRequestValue');

Rx.Observable.fromEvent(searchInput, 'input')
  .debounceTime(300)
  .map(e= > e.target.value)
  .subscribe((value) = > {
    theRequestValue.textContent = value;
    // Send request here
  })Copy the code

JSBin | JSFiddle

Try it out with JSBin and annotate debounceTime(300) to see the difference.

throttle

Basically, you’ll see Throttle every time you see Debounce, and both of them work to reduce the event’s firing rate, but their behavior is very different.

Like Debounce, RxJS has throttle and throttleTime. One is an Observable and the other is a millisecond. ThrottleTime is also commonly used

var source = Rx.Observable.interval(300).take(5);
var example = source.throttleTime(1000);

example.subscribe({
    next: (value) = > { console.log(value); },
    error: (err) = > { console.log('Error: ' + err); },
    complete: (a)= > { console.log('complete'); }});/ / 0
/ / 4
// completeCopy the code

JSBin | JSFiddle

Unlike Debounce, Throttle will release elements first, then silence them for a while when they are released, and then release them again when the time is up.

Throttle is more like the maximum frequency at which the behavior is controlled, meaning that if we set it to 1000 milliseconds, the event will fire once per second and no faster, whereas debounce is more like the time you have to wait until a certain amount of time has passed before the element is received.

Throttle is more suitable for continuous behavior, such as UI animation, because UI animation is continuous, like when we were doing drag, we could add throttleTime(12) to prevent mousemove events from being sent too fast, Avoid updating the screen faster than switching styles.

Browsers have a requestAnimationFrame API dedicated to optimizing UI operations, which is often better than throttle, but not always the end result.

RxJS can also be optimized with requestAnimationFrame, and it is very simple to use, which is mentioned in Scheduler.

Today’s summary

Today introduced two very practical methods, can help us do program performance optimization, and the use of the way is very simple, do not know readers have harvest? If you have any questions, feel free to leave a comment below. Thank you.