You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2024. It is now read-only.
I don't know why zone was designed to not have a rootZoneSpec, but in my understanding, if there is a rootZoneSpec just like your PR #521, everybody can modify the rootZoneSpec so the whole system may have unstable behavior.
for example,
you app have 2 modules,
moduleA will set rootZoneSpec.onHandleError to output log, moduleB will set rootZoneSpec.onHandleError to do other stuffs. That will cause the system in a unpredictable state.
I think it's the one reason that why we can't access zoneSpec at any time, the zoneSpec's behavior (ZoneDelegate's callback) can be only defined when we create the zoneSpec.
I think this feature expands zone.js' use cases, like this one #422 ,
In my case I need to be notified about every event for performance analysis, and I can't run the whole page inside a zone.
Also, even without this change there's the possibility of monkey patching root zone, (or even monkey patching browser api directly for that matter).
In regards to going into an unpredictable state, I think different modules can modify browser API however they want. I don't think this feature provides more than what is already possible in browsers.
yeah, I agree with you, in fact , I need such kind of feature too. I have a suggestion that should we remove rootZoneSpec from global after the rootZone has been created?
In your PR, the code like this, after rootZone created, delete it from global so no other code can access it from outside expect who created it.
Sorry, but this is by design. RootZone should be indistinguishable for no zone at all. This requirement is here so that if we standardize the Zones in TC39, the browser vendors will not have to pay the cost for all of the applications. All zones must be entered explicitly.
Activity
feat(Zone): check global for rootZoneSpec
JiaLiPassion commentedon Nov 25, 2016
I don't know why zone was designed to not have a rootZoneSpec, but in my understanding, if there is a rootZoneSpec just like your PR #521, everybody can modify the rootZoneSpec so the whole system may have unstable behavior.
for example,
you app have 2 modules,
moduleA will set rootZoneSpec.onHandleError to output log, moduleB will set rootZoneSpec.onHandleError to do other stuffs. That will cause the system in a unpredictable state.
I think it's the one reason that why we can't access zoneSpec at any time, the zoneSpec's behavior (ZoneDelegate's callback) can be only defined when we create the zoneSpec.
hmdhk commentedon Nov 27, 2016
I think this feature expands zone.js' use cases, like this one #422 ,
In my case I need to be notified about every event for performance analysis, and I can't run the whole page inside a zone.
Also, even without this change there's the possibility of monkey patching root zone, (or even monkey patching browser api directly for that matter).
In regards to going into an unpredictable state, I think different modules can modify browser API however they want. I don't think this feature provides more than what is already possible in browsers.
JiaLiPassion commentedon Nov 28, 2016
yeah, I agree with you, in fact , I need such kind of feature too. I have a suggestion that should we remove rootZoneSpec from global after the rootZone has been created?
In your PR, the code like this, after rootZone created, delete it from global so no other code can access it from outside expect who created it.
hmdhk commentedon Nov 28, 2016
@JiaLiPassion , Good call 👍 , Done.
feat(Zone): check global for rootZoneSpec
mhevery commentedon Dec 18, 2016
Sorry, but this is by design. RootZone should be indistinguishable for no zone at all. This requirement is here so that if we standardize the Zones in TC39, the browser vendors will not have to pay the cost for all of the applications. All zones must be entered explicitly.
feat(Zone): check global for rootZoneSpec
feat(Zone): check global for rootZoneSpec
feat(core): fix angular#1024, angular#513, angular#995, add a helper …
feat(core): fix angular#1024, angular#513, angular#995, add a helper …
1 remaining item