The following (primitive) APIs are being pursued currently:
Knowledge of whether input is pending, and the type of input. This is covered here: https://github.com/tdresser/should-yield
JS schedulers are estimating the time to next animation frame with book-keeping, but it's not possible to estimate this properly without knowing browser internals. The IsFramePending API allows script to determine when there is a pending frame to help with yielding decisions.
Link: https://github.com/szager-chromium/isFramePending/blob/master/explainer.md
Schedulers need to execute "default priority" work immediately following the document lifecycle (style, layout, paint). Currently they use workarounds to target this with:
- postmessage after each rAF (used by ReactScheduler):
- messagechannel workaround (google3 nexttick used by Maps etc): use a private message channel to postMessage empty messages; also tacked on after rAF. A bug currently prevents yielding.
- settimeout 0: doesn’t work well, in Chrome this is clamped to 1ms and to 4ms after N recursions.
Link: https://github.com/szager-chromium/requestPostAnimationFrame/blob/master/explainer.md
We are also thinking about the following problems. Note that these are not currently being pursued as API proposals, they are noted here for completeness and as a seed for discussion.
Interleaved reads and writes of dom result in layout thrashing. Today this is tackled with scheduling patterns like fast-dom and enforcement that goes along with this such as strict-dom.
Ideally, the read phase would occur immediately after style and layout have finished; and this would be followed by the write phase (default). A first class callback would allow developers to perform a clean read at the appropriate time.
A mechanism to inherit and propagate scheduling priority across related async calls: fetches, promises etc. Similar in spririt to zone.js.