Angular.js: Introduce Zones into AngularJS

Created on 25 Aug 2017  路  13Comments  路  Source: angular/angular.js

I'm submitting a ...

  • [ ] bug report
  • [x] feature request
  • [ ] other (Please do not submit support requests here (see above))

Current behavior:

Currently AngularJS utilises $http service and $q for promises, which are tied to Angular execution context (the famous digest cycle). Introducing Zones into AngularJS and connecting it to the execution context would mean people could use native Promises instead of $q promise and use native Fetch API instead of $http.

Expected / new behavior:

It would move AngularJS forward so people could use latest tech with it and not be tied too much into what the framework has to offer. For example people could begin to use native Promises and Fetch API instead of $http, and many other asynchronous tasks without depending too much on what the framework has to offer, because it's very limited.

Minimal reproduction of the problem with instructions:

AngularJS version: 1.x.y

Browser: [all | Chrome XX | Firefox XX | Edge XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Anything else:

misc core feature

Most helpful comment

@frederikprijck Thank you. However there are not everyone that would like to upgrade to Angular with NgUpgrade strategy. We are more looking for a exit strategy to React utilising ui-router for React. That's why this is necessary and should be implemented in AngularJS as well.

I took a look at this _angular1-zones_ implementation but it's using a legacy Zone (0.5.15) and doesn't quite work for all scenarios. Look here: https://stackoverflow.com/questions/45827733/replacing-http-with-fetch-api

All 13 comments

Please have a look at the following comment: https://github.com/angular/angular.js/issues/11370#issuecomment-321630113

TLDR (coz @gkalpak likes to write novels): AngularJS has been rewritten with this in mind, leading to Angular. With Angular and zones, the need for $http, $q etc is gone .

Dropping $http and using zones requires to also change the way AngularJS' change detection works. Basicly this is alot of rewriting and isn't going to land in AngularJS (anytime soon), coz that would require to do the same work twice (the refactor has already been done, leading to Angular).


If you realy want zones, you might want to have a look at https://github.com/oricalvo/angular1-zones (not that this is the best bet from a performance perspective tho)

@frederikprijck Thank you. However there are not everyone that would like to upgrade to Angular with NgUpgrade strategy. We are more looking for a exit strategy to React utilising ui-router for React. That's why this is necessary and should be implemented in AngularJS as well.

I took a look at this _angular1-zones_ implementation but it's using a legacy Zone (0.5.15) and doesn't quite work for all scenarios. Look here: https://stackoverflow.com/questions/45827733/replacing-http-with-fetch-api

Ofcourse it's not going to work in all situations, but the change you're asking for is far from trivial.
Doing such a change in order to provide an exit strategy towards another framework is a bit of an odd perspective to look at it.

Using zonejs and dropping $http (etc) in AngularJS will definetly be a major breaking change which will be almost as hard to upgrade to as towards Angular. (which in the end is what happend when Angular was released ... )

You can't expect AngularJS to change it's entire internal way of working, without the need for the user to put quite some effort in migrating.

I took a look at this angular1-zones implementation but it's using a legacy Zone (0.5.15)

Not that hard to create your own module using the latest zonejs, right ? But I still don't like that implementation tho.


If you have the need to use Promises API to allow you to easily migrate, you might be able to use the following (even tho I don't like this approach, it might help you in what you're trying to achieve:

window['Promise'] = $q

Note: this might (and probably will) break other libraries which use Promises.

@frederikprijck Why is it odd? AngularJS has no real future so they built Angular and have provided NgUpgrade as upgrade path from AngularJS. However, not everyone are willing to upgrade to Angular and would like to look at other options, for example React, Preact, Inferno, Vue.js, Aurelia or whatever that has the same component architecture. So for these people it would be benficial to integrate Zones into AngularJS as well. The work has been done and it's quite clear what needs to be done, so I would say it's very well possible.

ui-router team did this (splitting into core package/functionality) to provide routing to other frameworks, but utilising the same core routing functionality/API. Then they built on top of that, for AngularJS and React. Then they can build a UI-Router for Vue.js, Preact, Aurelia, etc. if they'd like.

so I would say it's very well possible.

I guess you could always drop in a PR to replace it in such a way that upgrading is trivial. If upgrading isn't trivial, people will probably don't want to be putting effort in upgrading only to use zones. 馃槵

If upgrading is trivial and performance isn't an issue, I'd guess alot of people will have interest in the PR.

But no, I don't think it's easy and neither is it going to be easy for an end user to upgrade his application (and what about all the 3th party libraries that will break, unless they are updated aswell ?).


Anyway, most of this has been explained at https://github.com/angular/angular.js/issues/11370#issuecomment-321630113

Thank you. According to #11370 @gkalpak they haven't ruled it out so there is still hope. 馃槃

I personally think the chances for this are very slim. You can already use ngUpgrade and Angular if you want zones. The main idea is to guide developers into upgrading to Angular, not give them big incentives to continue using AngularJS.

Phrase do not add Zones to AngularJS. We have a strict no monkey patching policy and so cannot support them

This is out of scope at this point of AngularJS development.

You could at least show us the decency to guide the AngularJS community towards an HTTP/AJAX/fetch solution that is decoupled from the digest cycle - without having to upgrade to Angular 2..N 馃槕

What has decency to do with this? We never made any commitment that this would happen, and $http is a solid service that will continue to work. In your own requests, you can use fetch instead of it easily as well.

@Narretz I apologise for the haste, but 1.x has no future so eventually you have to evacuate, so people either have to upgrade to 2+ and continue from there, or introduce some kind of a hybrid solution, to be able to use something that has a future. But without $http , you have to cook up some digest cycle hack around your fetch/XHR, which creates a world of headache when you have a large application and multiple async operations. Without zones, this is hard.

or introduce some kind of a hybrid solution

As already mentioned (even by yourself), you could always spent some time to integrate ngUpgrade in your application and move forward with that untill your entire application has been ported to Angular.

New code can be written in Angular, make use of Zones and have no need to worry about AngularJS' digest cycle.

More info: https://angular.io/guide/upgrade

We've used it in several apps and it works great (even tho it does take quite some time to be able to integrate it)

guide the AngularJS community towards an HTTP/AJAX/fetch solution that is decoupled from the digest cycle

I don't think there's possibilities to guide anyone to this, without rewriting AngularJS' way of doing change detection. Today, in AngularJS, async operations need the digest cycle. Btw, this rewrite has already been done, which eventually led to Angular because it needed way to many breaking changes.

Was this page helpful?
0 / 5 - 0 ratings