Investigate microtask queueing once it's implemented

[danielcompton]

Microtask Queuing looks like it may be useful for us in the re-frame router loop. However, it is still a long way from implementation.

• https://bugs.chromium.org/p/chromium/issues/detail?id=864900
• https://bugs.webkit.org/show_bug.cgi?id=188212
• https://bugzilla.mozilla.org/show_bug.cgi?id=1480236
• https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/35006017-implement-self-queuemicrotask

See also whatwg/html#2789.

[superstructor]

As I understand it, Microtask Queuing was introduced for use cases related to promises and async functions, for code to run after the currently-executing task has run to completion and the JavaScript execution context stack is empty, but without yielding control back to the browser’s event loop. In effect, for scenarios in which control can’t be passed back to the browser’s main event loop, before the scheduled task is actioned.

Re-frame doesn’t need that guarantee. The existing method for scheduling processing of the event queue works well enough. I can’t see a driver for making a change away from the existing method, particularly when nothing is currently wrong and any change might actually introduce subtle new problems.

Closing.