Adding Event Listeners outside of the NgZone

If we're familiar with the Angular framework, we'll know that by default, any asynchronous event triggers the change detection process. In certain situations, we don't even have to worry about it; it just works as expected. However, in some cases, running the change detection process too frequently can lead to poor runtime efficiency.

Table of Content

Execution of code in the NgZone

Assume that we want to call the console.log method when we click the button:

Click handler in NgZone

import { AfterViewChecked, Component } from "@angular/core";

@Component({
  selector: "my-app",
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"]
})
export class AppComponent implements AfterViewChecked {

  onClick() {
    console.log("onClick");
  }

  ngAfterViewChecked() {
    console.log("CD performed");
  }
}

// console output: onClick, CD performed

When we click the button, both the bound event listener and the change detection process are triggered. In a real-world scenario, instead of calling console.log, we could perform an action that does not require bindings to be updated.

Incorrect usage of the runOutsideAngular method

Although the method in question allows us to opt-out of the change detection process, it must provide code to register an event listener. As a result, the following solution, which simply runs the callback outside of the NgZone, will not prevent the change detection process from being performed:\

import { AfterViewChecked, Component, NgZone } from "@angular/core";

@Component({
  selector: "my-app",
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"]
})
export class AppComponent implements AfterViewChecked {

 constructor(private readonly zone: NgZone) {}

  onClick() {
    this.zone.runOutsideAngular(() => {
      console.log("onClick");
    });
  }

  ngAfterViewChecked() {
    console.log("CD performed");
  }
}

// console output: onClick, CD performed

Execution of code outside of the NgZone - using ViewChild

We may use the ViewChild decorator to get a reference to the DOM node and add an event listener in one of the following ways:

Click handler outside NgZone

As a result, clicking the button won't trigger the change detection process.

Execution of code outside of the NgZone - using directive

While the previous paragraph's solution works well, it is a little verbose. we can encapsulate the logic in an attribute directive, which allows dependency injection to provide easy access to the underlying DOM element (ElementRef token). Then, outside of the NgZone, we can add an event listener and emit an event when it's appropriate:

Click handler outside NgZone

The OnDestroy hook is ideal for removing the event listener and preventing memory leaks. We may apply the directive and register the event's handler in a single statement if we use the name alias for the event emitter.

Execution of code outside of the NgZone - using Event Manager Plugin

The directive-based approach has the disadvantage of not being able to be configured for an event type. Thankfully, Angular allows us to build our Event Manager Plugin. In other words, we take control of adding a listener for an event whose name corresponds to the predicate function (the supports method). If a match is found, the addEventListener method is called, allowing us to handle the job. The two methods are part of the user-defined service that is registered as an EVENT MANAGER PLUGINS token provider:

Click handler outside NgZone

Be Afraid of third-party Code

3rd party lib initialized in NgZone

It works perfectly, but the change detection process is repeated every time we hover over the button element. It is undeniably redundant because the tooltip element is imperatively added to the DOM using the native API (no need to update bindings in template). Fortunately, by calling the initialization code from outside the NgZone, we can avoid triggering the change detection process:

Fortunately, by calling the initialization code from outside the NgZone, we can avoid triggering the change detection process:

3rd party lib initialized outside NgZone

Conclusion

If we find ourselves in a situation where we are performing a task that does not need binding updates in response to a DOM event, we can improve the performance of our application by not triggering an unwanted change detection run Outside of the NgZone, we must be careful when registering an event listener. The most elegant and reusable solution is to use a custom Event Planner Plugin. If we're using a third-party solution that modifies the DOM, we should think about running its initialization code outside of the NgZone.