We handle several kinds of tasks in zone.js,
- MacroTask
- MicroTask
- EventTask
For details, please refer to here
And in this documentation, it will explain the task lifecycle about which callback of zoneSpec will be triggered when.
The motivation to write this because of this PR of @mhevery. That task's state become more clear and can be rescheduled and override.
Such as Promise.then, process.nextTick, they are microTasks, the lifecycle(state transition) looks like this.
ZoneSpec's onHasTask callback will be triggered when the first microTask were scheduled or the last microTask was invoked.
Such as EventTarget's EventListener, EventEmitter's EventListener, their lifecycle(state transition) looks like this.
ZoneSpec's onHasTask callback will be triggered when the first eventTask were scheduled or the last eventTask was cancelled.
EventTask will go back to scheduled state after invoked(running state), and will become notScheduled after cancelTask(such as removeEventListener)
Such as setTimeout/XMLHttpRequest, their lifecycle(state transition) looks like this.
ZoneSpec's onHasTask callback will be triggered when the first macroTask were scheduled or the last macroTask was invoked or cancelled.
Non periodical macroTask will become notScheduled after being invoked or being cancelled(such as clearTimeout)
Such as setInterval, their lifecycle(state transition) looks like this.
ZoneSpec's onHasTask callback will be triggered when first macroTask was scheduled or last macroTask was cancelled, it will not triggered after invoke, because it is periodical and become scheduled again.
Periodical macroTask will go back to scheduled state after invoked(running state), and will become notScheduled after cancelTask(such as clearInterval)
Sometimes you may want to reschedule task into different zone, the lifecycle looks like
the ZoneTask's cancelScheduleRequest method can be only called in onScheduleTask callback of ZoneSpec, because it is still under scheduling state.
And after rescheduling, the task will be scheduled to new zone(the otherZoneSpec in the graph), and will have nothing todo with the original zone.
Sometimes you may want to just override the zone when scheduling, the lifecycle looks like
After overriding, the task will be invoked/cancelled in the new zone(the otherZoneSpec in the graph), but hasTask callback will still be invoked in original zone.
