[question] The relationship between the scheduling APIs and built-in functions.

[JiaLiPassion]

Hi, I am currently working on the zone.js project, zone.js monkey patches the native scheduler APIs such as setTimeout, Promise.then to monitor the async operations. So I have several questions about this new scheduling API.

1. The priority of the new scheduling API is user blocking, user-visible and background, what is the relationship with the traditional macroTask and microTask?
2. If the new scheduling API is released, will the current built-in APIs such as setTimeout and Promise.then also call this scheduling API internally?
3. async/await will schedule microTask internally, if the new scheduling API is released, will the async/await also use this scheduling API internally?
4. Is that possible to implement customized scheduler provided by user, the purpose is to add some logic to when schedule a task so the user can monitor the status of the async task. Or at lease allow to monkey patch the postTask API.

Thank you.

[shaseley]

Hi, I am currently working on the zone.js project, zone.js monkey patches the native scheduler APIs such as setTimeout, Promise.then to monitor the async operations. So I have several questions about this new scheduling API.

Hi @JiaLiPassion, thanks for the questions! Note: we shipped scheduler.postTask in Chromium in M94, and what I'm describing below is the current state of the implementation.

1. The priority of the new scheduling API is user blocking, user-visible and background, what is the relationship with the traditional macroTask and microTask?

Tasks scheduled with scheduler.postTask() are macrotasks. The priority helps the event loop's scheduler order them with respect to other macrotasks (kind of illustrated in this diagram). postTask returns a promise that is resolved with the result of the callback function (which could be a promise). The microtasks associated with this promise are handled in the normal fashion (i.e. microtask checkpoints).

2. If the new scheduling API is released, will the current built-in APIs such as setTimeout and Promise.then also call this scheduling API internally?

Promise.then: Right now the scheduler only deals with macrotasks, aside from postTask returning a Promise, and there are no plans for microtasks to go through the scheduler. Macrotasks that resolve microtasks (e.g. fetch() completions) might eventually go through scheduler internally, but Promise.then is a pure JS engine thing and that's not on our radar at the moment.

setTimeout and scheduler.postTask both go through the event loop scheduler internally—which decides how to schedule between them—but that's the extent of it right now. We've floated the idea of defining setTimeout in terms of postTask in order to specify a priority for setTimeout, but it's not clear if we should or will.

3. async/await will schedule microTask internally, if the new scheduling API is released, will the async/await also use this scheduling API internally?

No. Similar to Promise.then, async/await happens in the JS engine which is a layer below scheduler. We don't have plans for this to go through the scheduler.

4. Is that possible to implement customized scheduler provided by user, the purpose is to add some logic to when schedule a task so the user can monitor the status of the async task. Or at lease allow to monkey patch the postTask API.

window.scheduler is implemented as replaceable, so you replace it with a custom implementation. You should be able to monkey patch postTask specifically as well.

Scheduler is not constructible, however, though we might be open to it given use cases. But we'd need to be careful since one goal of the scheduler API is to provide a common scheduler across a page.

Thank you.

I also want to mention that we're also investigating ideas around defining async tasks and async task propagation, which from previous discussions with Angular folks might be of interest to you. This has overlap with zones and likely requires us to know more about microtasks, e.g. the scheduler.currentTaskSignal prototype hooks into .then in order to save off task context. I'm hoping to post updates on our thinking here in the next few months.

[JiaLiPassion]

@shaseley , thank you very much for the reply, now I have a more clear understanding, I will read the docs about the scheduler.currentTaskSignal to find out whether I can do something with zone.js.