[Question] Resize Debounce Time

[jd-carroll]

Is there a specific reason why the debounce delay is set to 200ms? My assumption is that this is an arbitrary amount of time that is used to ensure the changes are fully reflected in the browser.

My understanding is that the resize event isn't fired by the browser until the resize has actually occurred. So I'm not certain that the delay is necessary, and instead of using Timer.debounce(fn, 200) I think Timer.debounceAfter(fn, 1) would be more appropriate.

[dmvaldman]

200 is definitely an arbitrary number. It's not clear that just waiting one frame will be enough either though, because the rate at which resize events are emitted is not tied to the request animation frame loop. I'll take a closer look though to test your suggestion. If resize events are called faster than the request animation frame, we're good (this may be hardware dependent, not sure if there's a spec). If not then a fudge factor (like 200ms) might be needed, though 200 is generous. Really there's no significant problem with having the end event fired 200ms after the last resize event. In the future, I'd like to manually limit the DOM events to fire at most once per request animation frame loop (taking the last event fired in the loop and ignoring the others).

For clarity on the code, the point of the debounce is to convert a continuously emitted resize event into start, update and end events to fit the architecture. The first resize event can easily be detected and converted to a start. The last one can only be detected with a debounce style call.

[dmvaldman]

After some testing, I've found the resize event to be triggered slower than the request animation frame loop. Browsers likely throttle the event internally. This forces us to keep a fudge factor, but I've decided to lower it slightly to 150ms.

Whatever value is chosen will cause a lag if there is a sudden resize event triggered. For instance, opening and closing the dev tools on a desktop browser, or changing the orientation from landscape to portrait (or vice versa) on a mobile app. The view won't update responsively for the duration of 150ms.

This is undesirable, however, at least on mobile you can detect for this (because the only resize events from orientation change are discrete in nature). So we can remove any lag on mobile orientation resizes.

This has been updated in 4f681de