requestTimeout based on requestAnimationFrame

We are noticing some performance issues with requestAnimationFrame and notice that react-window does a lot of calls with that.

The root for this is:

    _resetIsScrollingDebounced = () => {
      if (this._resetIsScrollingTimeoutId !== null) {
        cancelTimeout(this._resetIsScrollingTimeoutId);
      }

      this._resetIsScrollingTimeoutId = requestTimeout(
        this._resetIsScrolling,
        IS_SCROLLING_DEBOUNCE_INTERVAL
      );
    };

Which use a rather peculiar requestTimeout which is based on polling requestAnimationFrame:

export function requestTimeout(callback: Function, delay: number): TimeoutID {
  const start = now();

  function tick() {
    if (now() - start >= delay) {
      callback.call(null);
    } else {
      timeoutID.id = requestAnimationFrame(tick);
    }
  }

  const timeoutID: TimeoutID = {
    id: requestAnimationFrame(tick),
  };

  return timeoutID;
}

I'm curious why this is used instead of simply using setTimeout? IS_SCROLLING_DEBOUNCE_INTERVAL is after all 150 ms and thus any reduced inaccuracy from setTimeout should not be relevant?

Is there something here I'm missing? Like is the scheduling priority important?

bvaughn / react-window

requestTimeout based on requestAnimationFrame #628