RichText: Fall back to setTimeout if no requestIdleCallback

[mcsf]

Description

See #14776 (comment). If window.requestIdleCallback isn't available, fall back to window.requestAnimationFrame window.setTimeout. This approach is also used in priority-queue:

gutenberg/packages/priority-queue/src/index.js

Line 1 in 9c58193

const requestIdleCallback = window.requestIdleCallback ? window.requestIdleCallback : window.requestAnimationFrame;

How has this been tested?

Make sure the behaviour introduced in #14776 is preserved both in environments that provide requestIdleCallback (e.g. Firefox) and those that don't (Safari).

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[ellatrix]

Oh, sorry, I saw usage when recording a performance profile, so I assumed it was fine. Unfortunately an animation frame won’t work I think. It will be too early if there’s multiple selection changes like the list input rule. Is there any other way to creat a fallback? Perhaps wait 100ms or so.

[mcsf]

Perhaps wait 100ms or so.

@ellatrix: I trust your judgment on those heuristics. Would you rather implement that with just setTimeout, or build something atop requestAnimationFrame?

[ellatrix]

@mcsf not sure if it matters or what the difference may be. The important thing is that all changes have been completed and all selection changes are done. That’s why I picked an idle period. This is also fine from a UX point of view cause you cannot realize an automatic change happened before an idle period to undo it. I think 100 ms or even less is fine to replace this, I don’t think it really matters how unless there’s some way to detect idleness. The nice thing about idleness is that you’re sure all work is done, no matter how slow the browser is.

[mcsf]

I think 100 ms or even less is fine to replace this, I don’t think it really matters how unless there’s some way to detect idleness. The nice thing about idleness is that you’re sure all work is done, no matter how slow the browser is.

Yeah, idleness is a lot nicer, but I'm fine with the trade-off that it might not be as smooth on browsers that haven't implemented requestIdleCallback yet. I've pushed another commit so that the fallback uses setTimeout(_, 100) instead of requestAnimationFrame. What do you think, @ellatrix?

[ellatrix]

Sounds good

[mcsf]

Thanks for the quick review!