search

angular / angular.js

AngularJS - HTML enhanced for web apps!
https://angularjs.org
MIT License
58.91k stars 27.55k forks source link

Expose NgZone stub service #16089

Open kseamon opened 7 years ago

kseamon commented 7 years ago

I'm submitting a ...

Current behavior:

AngularJS code by default does not have access to a Zone (as it typically does not exist). However, in NgUpgrade the NgZone can be injected. Since some AngularJS code may be used in vanilla AngularJS as well as NgUpgrade contexts, it is awkward to include performant handling of zones without breaking the AngularJS version.

Expected / new behavior:

A service is exposed that includes the run and runOutsideAngular methods. In AngularJS, these are just stubs that call the callback with no side effects. In an NgUpgrade context, they call the same methods on the actual NgZone.

Minimal reproduction of the problem with instructions:

Angular version: 1.*

Browser: all]

Anything else:

gkalpak commented 7 years ago

So, the idea is to be able to write AngularJS code that would run both on AngularJS and ngUpgrade apps? Although this would be convenient for people interested in that scenario, I feel it will be confusing for people that are not familiar with Angular/Zone.js/ngUpgrade.

Any reason (other than convenience) why this can't be a stand-alone module? (Maybe it could be distributed as part of ngUpgrade. Or in the future, we might have more similar helpers in something like @angular/upgrade/angularjs-helpers :smiley:)

(I am not saying I am opposed to adding this in core - I would like to think it through/discuss more :grin:)

kseamon commented 7 years ago

It would be fine to put it in a non-core module. The only argument against that is that it would be useful inside of the AngularJS codebase for making things like $timeout faster when in NgUpgrade.

kseamon commented 7 years ago

It would make sense for the "real" version to be hooked up as part of NgUpgrade. The stub version (which should be only several lines of code) would be part of the normal AngularJS codebase.

The whole point is that shared AngularJS components/services that don't know which kind of codebase they are being used in can assume the presence of this service.

gkalpak commented 6 years ago

I see. That makes sense. It also has some downsides, but there is no ideal solution here, I guess. I would still prefer to keep it as a separate module if possible (in angular/angular.js) - at least the public API of it.