Opt out of Zone.js event patching in ngUpgrade

[thelgevold]

I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
Currently zone.js patches all native events like click, mousemove, keydown, etc to automatically trigger change detection cycles.

This is very convenient in pure Angular applications, but I have some concerns with this approach in ngUpgrade applications. Once patched, it appears that all handlers are enlisted in the Angular (4+) zone. Even the handlers that belong to Angular 1 code.

A side effect of this is that digest cycles are fired in the Angular 1 application every time one of the patched event handlers are invoked.

Example: If I have a mousemove handler registered in Angular 1, a digest is now triggered every time I move the mouse. This is similar to using ng-mousemove, but undesirable if you used mousemove in Angular 1, specifically to avoid digest cycles on every mouse move.

Expected behavior
The fix I have seen is to run the event handler for the Angular 1 event in the "parent" zone:

$window.Zone.current.parent.run(function() {
        $('body').on('mousemove', function(){
           console.log('triggered');
        });
});

I think it would be better if the parent zone was the default for Angular 1 events, instead of being available as an opt-in.

It makes sense that downgraded components have to run in the "change detection aware" zone, but this does not seem appropriate for existing Angular 1 handlers - at least not as the default.

Minimal reproduction of the problem with instructions
Register any native event handler in an ngUpgrade application

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 4.0.X

• Browser: [all

• Language: [TypeScript]

[djpark]

+1. I currently have a hybrid AngularJS/Angular app that uses the ngIdle library. NgIdle hooks up handlers for DOM events like mousemove, scroll, etc. which end up triggering change detection due to zonejs' monkey patching of these events.

Similarly to @thelgevold, I'm working around this by running the event handler hookup outside of Angular zone. The additional step I need to take in my case (given that the event hookup is happening in an external library) is to manually find/remove the event listeners then re-add them inside of the runOutsideAngular() call.

Would be great to avoid having to do this by having events hooked up in Angular 1 context run outside of zone by default.

[jbedard]

I think I've said similar in another issue, but I wonder if ng-upgrade should try to use the parent zone for things like:

• directive link functions
• $timeout(..., invokeApply = false) and other invokeApply = false methods

Or would this cause too much inconsistency because this isn't possible everywhere?

[gkalpak]

The new downgradeModule() will take care of that (running AngularJS outside the Angular zone). (Docs coming in #18487.)

It is still under consideration whether to make it configurable if AngularJS runs inside or outside the Angular zone.

_{Closing this, but feel free to continue the discussion below.}

[blingerson]

@gkalpak, is this slated to be in the next version 4.4.7? Is there a workaround or patch that can be applied in the meantime?

[gkalpak]

No, @blingerson, downgradeModule() is a 5.x-only feature.

There is no workaround I can recommend in good faith 😃
You might want to bootstrap AngularJS outside the Angular zone, which means that async operations that happen in AngularJS-land will not trigger CD in Angular (and subsequently CD in AngularJS again).
But CD will still be triggered in AngularJS when onMicrotaskEmpty is triggered on the Angular zone and you might see unexpected behavior in more complex cases, with changes in one part of the app not properly propagating to the rest of the app.

[blingerson]

Thank you @gkalpak, I hadn't yet realized 5.0 was released!

One quick question about the downgradeModule being used in conjunction with downgradeInjectable...

Since downgrade module is utilized after angular 1 is bootstrapped how do you add a "downgradeInjectable" service to the angular 1 DI tree given that Angular 5+ is not bootstrapped yet and therefore the angular injector is not available?

For example:

File 1.....

@Injectable()
export class MyService implements OnInit{
    constructor(
        @Inject( 'someOtherInjectable' ) public someOtherInjectable : SomeOtherInjectable,
    ) {
}

File 2....

angular.module( 'myServicesModule', [] )

.factory(
    'myServiceDowngraded',
    downgradeInjectable( MyService ),
).name;

In this example an error is thrown:
Uncaught Error: Trying to get the Angular injector before bootstrapping an Angular module.

https://stackoverflow.com/questions/47189917/using-downgrademodule-in-conjunction-with-downgradeinjectable-in-an-angular-an

[thelgevold]

My understanding is that you can't use downgraded injectables in AngularJS code if you use downgradeModule.

I found an article here: https://pr18487-aedf0aa.ngbuilds.io/guide/upgrade-performance that makes this point

[blingerson]

Thank you @thelgevold, that makes sense

[gkalpak]

Just to be clear:
You can use downgradeInjectable() with downgradeModule(), but there are certain limitations. In particular, you cannot try to inject a downgraded injectable until Angular has been bootstrapped. And Angular is bootstrapped (asynchronously) the first time a downgraded component is being rendered. So, you can only safely use a downgraded service inside a downgraded component (i.e. inside upgraded AngularJS components).

I know this is limiting enough that you might decide to not use downgradeInjectable() at all - just wanted to make it more clear what you can and can't do.

Note that the equivalent limitation is true when using an upgraded injectable with UpgradeModule: You cannot use it until AngularJS has been bootstrapped. This limitation usually goes unnoticed though, because AngularJS is usually bootstrapped in the Angular module's ngDoBootstrap() method and AngularJS (unlike Angular) bootstraps synchronously.

[mralbobo]

So...what does the recommended implementation look like in the case where you want an injectable/ service accessible to the entire app (both the angular and angularjs side), and UpgadeModule hits performance like a truck.

Creating a new angularjs service and upgrading it seems counter-intuitive, and I think wrapping the entire angularjs app in an upgraded component would just put it back in the angular zone? Defeating the point of bootstrapping outside the zone.

[gkalpak]

Unfortunately, I don't think there is a good answer atm. Upgraded components are indeed run inside the ngZone (which is something that we could reconsider, but will be a breaking change). It will not be as bad as using UpgradeModule (because you still won't have the $rootScope.$digest() on onMicrotaskEmpty(), but still... 😞