Skip to content
This repository was archived by the owner on Feb 26, 2024. It is now read-only.

Configuring Root zone #513

Closed
hmdhk opened this issue Nov 22, 2016 · 5 comments
Closed

Configuring Root zone #513

hmdhk opened this issue Nov 22, 2016 · 5 comments

Comments

@hmdhk
Copy link
Contributor

hmdhk commented Nov 22, 2016

Is there a way to configure onScheduleTask and onInvokeTask on the root zone?
Or other interceptions for that matter?

hmdhk added a commit to hmdhk/zone.js that referenced this issue Nov 25, 2016
@JiaLiPassion
Copy link
Collaborator

JiaLiPassion commented 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
Copy link
Contributor Author

hmdhk commented 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
Copy link
Collaborator

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.

 const symbolRootZoneSpec = '__rootZoneSpec__'
 var rootZone: Zone = new Zone(null, null);
 if (global[symbolRootZoneSpec]) {
   rootZone = <Zone>rootZone.fork(global[symbolRootZoneSpec]);
   delete global[symbolRootZoneSpec];
 }
 +

@hmdhk
Copy link
Contributor Author

hmdhk commented Nov 28, 2016

@JiaLiPassion , Good call 👍 , Done.

hmdhk added a commit to hmdhk/zone.js that referenced this issue Dec 6, 2016
@mhevery
Copy link
Contributor

mhevery commented 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.

@mhevery mhevery closed this as completed Dec 18, 2016
hmdhk added a commit to hmdhk/zone.js that referenced this issue Dec 29, 2016
closes angular#513

remove symbolRootZoneSpec from global

using let instead of var

add missing semicolon
hmdhk added a commit to hmdhk/zone.js that referenced this issue Dec 29, 2016
closes angular#513

remove symbolRootZoneSpec from global

using let instead of var

add missing semicolon
JiaLiPassion added a commit to JiaLiPassion/zone.js that referenced this issue Feb 23, 2018
JiaLiPassion added a commit to JiaLiPassion/zone.js that referenced this issue Feb 23, 2018
JiaLiPassion added a commit to JiaLiPassion/zone.js that referenced this issue Feb 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants