New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Zone.onEnter / onLeave #17532

Open
floitschG opened this Issue Mar 17, 2014 · 3 comments

Comments

Projects
None yet
4 participants
@floitschG
Contributor

floitschG commented Mar 17, 2014

It would be convenient to have a callback for zone.onEnter and zone.onLeave in the ZoneDescriptions.

@lrhn

This comment has been minimized.

Show comment
Hide comment
@lrhn

lrhn Oct 6, 2014

Member

Removed Type-Defect label.
Added Type-Enhancement label.

Member

lrhn commented Oct 6, 2014

Removed Type-Defect label.
Added Type-Enhancement label.

@Sharom

This comment has been minimized.

Show comment
Hide comment
@Sharom

Sharom Aug 8, 2017

Hi. Will it be implemented? It would be very convenient.

Sharom commented Aug 8, 2017

Hi. Will it be implemented? It would be very convenient.

@lrhn

This comment has been minimized.

Show comment
Hide comment
@lrhn

lrhn Aug 9, 2017

Member

I'm wary about adding more overhead to zone entry/exit (it will cost, at least one lookup of "is onZoneEnterOrExit overridden").

At a fundamental level, a zone isn't being "enterede" and "exited", it's just that the currently executing code has a zone associated with it. That zone can be changed in a number of ways, mostly by Zone.run, but internally (e.g., in the microtask queue) it's also being done just by selecting the zone and running the code.

Entering a zone is usually somewhat well-delimited, but exiting is harder to define. Are you exiting a zone when you enter another zone with zone.run? Are you reentering the original zone when that call returns? Does it matter whether the new zone is/is not a child of the original zone? Maybe you should only call onExit when you switch to a zone that has a different onEnter/onExit implementation registered, not one that inherits the current one (like we do for error handlers). But that might add even more overhead in the checks, or maybe it's just one identical check on the _onEnterExitHandler property.

In any case, it's not without cost, even if you don't use it. There is no such thing as a free lunch :)

Member

lrhn commented Aug 9, 2017

I'm wary about adding more overhead to zone entry/exit (it will cost, at least one lookup of "is onZoneEnterOrExit overridden").

At a fundamental level, a zone isn't being "enterede" and "exited", it's just that the currently executing code has a zone associated with it. That zone can be changed in a number of ways, mostly by Zone.run, but internally (e.g., in the microtask queue) it's also being done just by selecting the zone and running the code.

Entering a zone is usually somewhat well-delimited, but exiting is harder to define. Are you exiting a zone when you enter another zone with zone.run? Are you reentering the original zone when that call returns? Does it matter whether the new zone is/is not a child of the original zone? Maybe you should only call onExit when you switch to a zone that has a different onEnter/onExit implementation registered, not one that inherits the current one (like we do for error handlers). But that might add even more overhead in the checks, or maybe it's just one identical check on the _onEnterExitHandler property.

In any case, it's not without cost, even if you don't use it. There is no such thing as a free lunch :)

@lrhn lrhn added the core-m label Aug 11, 2017

@floitschG floitschG added core-l and removed core-m labels Sep 11, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment