Forem: Jordi Riera

Mastering Angular's Change Detection Strategies for Enhanced Performance

Jordi Riera — Sun, 02 Apr 2023 22:56:52 +0000

Introduction

Achieving high-performance in Angular applications often relies on understanding and optimizing change detection. Change detection refers to the process by which Angular monitors and updates the UI to reflect data changes. The default change detection strategy may suffice for many applications, but optimizing it can lead to even better performance.

In this post, we'll dive deeper into Angular's change detection mechanism and discuss advanced optimization techniques to maximize your application's performance. Buckle up for an exciting trip to deeper parts of Angular change detection!

Picture by Gabriel Valdez at Unsplash

Change Detection Optimization Strategies

Profiling Change Detection Performance

Before optimizing change detection, it's essential to profile your application's performance to identify bottlenecks. Using tools like the Angular DevTools extension for Chrome, you can inspect your component tree and visualize change detection cycles and pinpoint areas that need optimization.

Zone.js and Angular's Change Detection

Photo by Enouch E:

So... what on earth is Zone,js? Zone.js is a library that intercepts asynchronous tasks and "notifies" Angular when tasks complete. By leveraging Zone.js, Angular can automatically trigger change detection when tasks like user interactions, timers, or HTTP requests finish. Understanding the role of Zone.js can help you fine-tune change detection, making your application more performant.

Zone.js Pollution and its Effects

Zone.js is designed to intercept and track all asynchronous operations in an application. However, this can sometimes lead to a phenomenon known as "Zone.js pollution," where unrelated asynchronous tasks trigger unnecessary change detection cycles, negatively impacting performance. By identifying and isolating such tasks, you can minimize the impact of Zone.js pollution on your application.

Using NgZone to Control Zone.js Behavior

NgZone is an Angular service that wraps Zone.js, providing a consistent interface for working with Zone.js in Angular applications. By using NgZone's runOutsideAngular() method, you can execute code outside of Angular's change detection mechanism, preventing unnecessary or redundant change detection cycles due to Zone.js pollution.

When should I consider this:

Your application includes third-party libraries that use asynchronous tasks, such as analytics, charts or real-time data streaming services. These tasks may cause unnecessary or redundant change detection cycles, degrading performance.

Code example:

import { NgZone } from '@angular/core';

constructor(private ngZone: NgZone) {}

// Running code outside of Angular's change detection
this.ngZone.runOutsideAngular(() => {
  // Your code here
});

Improving ChangeDetectionStrategy.OnPush

Photo by Devon Janse van Rensburg at Unsplash

We know that one of the ways to improve performance in a component is using OnPush change detection strategy. We reduce the amount of things that angular needs to keep track of (namely Input changes, events oroginated from the component and observable new emissions in the async pipe, although the last one is technically a markForCheck() strategy) However, we can improve the performance of the OnPush strategy by following these tips to further optimize your application's performance:

1.Debounce Input Changes

If your component receives rapid input changes, debounce the changes to reduce the number of change detection cycles triggered.

When should I consider this:

Your application has input components, such as search bars or sliders, that receive rapid input changes and cause excessive change detection cycles.

Code Example:

import { debounceTime } from 'rxjs/operators';

// Debouncing input changes
this.searchInput.valueChanges.pipe(
  debounceTime(300)
).subscribe(value => {
  this.search(value);
});

2.Optimize Observables

Use operators like distinctUntilChanged() or shareReplay() to limit unnecessary emissions and optimize change detection cycles.

When should I consider this:

-Your application uses RxJS Observables extensively, and you need to ensure that only necessary emissions trigger change detection cycles.

Code Example:

import { distinctUntilChanged, shareReplay } from 'rxjs/operators';

// Using distinctUntilChanged and shareReplay operators
this.data$ = this.dataService.getData().pipe(
  distinctUntilChanged(),
  shareReplay(1)
);

Other optimization strategies for smoother change detection cycles

Photo by Miguel Á. Padriñán:

To further optimize change detection performance, consider the following strategies:

1. Immutable Data:

By using immutable data structures, you can ensure that data changes only when necessary. This can significantly reduce the number of change detection cycles, as Angular will only need to check for reference changes instead of deep object comparisons.

When should I consider this:

-Your application uses large data objects that frequently change, causing performance issues due to excessive deep object comparisons during change detection cycles.

Code Example:

import { List } from 'immutable';

// Mutable array of objects
const mutableData = [
  { id: 1, name: 'Item 1' },
  { id: 2, name: 'Item 2' },
  { id: 3, name: 'Item 3' },
];

// Converting mutable data to an immutable List of objects
const immutableData: List<object> = List(mutableData);

console.log('Immutable data:', immutableData);

// Updating an item in the immutable data (returns a new List)
const updatedImmutableData = immutableData.set(1, { ...immutableData.get(1), name: 'Updated Item 2' });

console.log('Updated immutable data:', updatedImmutableData);

2.Batch Updates:

Accumulate multiple data changes before updating the UI, reducing the frequency of change detection cycles. This can be done by using techniques like debouncing or throttling.

3.Using ChangeDetectorRef:

The ChangeDetectorRef service allows you to manually mark components as needing change detection. This can be useful when working with asynchronous tasks that are not automatically tracked by Zone.js, or when using third-party libraries that operate outside Angular's change detection mechanism.

When should I consider this:

-Your application integrates with third-party libraries that operate outside Angular's change detection mechanism, and you need to ensure that the UI updates when the data changes.

Code Example:

import { ChangeDetectorRef } from '@angular/core';

constructor(private cd: ChangeDetectorRef) {}

// Triggering change detection manually
this.cd.detectChanges();

----
// Marking a component for check
this.cd.markForCheck();

4.Utilize TrackBy with *ngFor

When using *ngFor with OnPush, use the trackBy function to minimize DOM manipulation and improve performance.

When should I consider this:

-Your application uses *ngFor to render large lists, and you need to minimize DOM manipulation to improve performance.

Code Example:

import { Component } from '@angular/core';

@Component({
  selector: 'app-list',
  template: `
    <ul>
      <li *ngFor="let item of items; trackBy: trackById">{{item.id}} - {{item.name}}</li>
    </ul>
  `
})
export class ListComponent {
  items = [
    { id: 1, name: 'Item 1' },
    { id: 2, name: 'Item 2' },
    // ...
  ];

  trackById(index: number, item: any): number {
    return item.id;
  }
}

Conclusion:

Mastering Angular's change detection strategies is vital for building high-performance applications. By understanding the intricacies of Angular's change detection mechanism and implementing advanced optimization techniques, you can significantly enhance your application's performance.

Finally if you have any questions or suggestions feel free to show up and comment!

Angular Dependency Injection Understood III

Jordi Riera — Mon, 14 Nov 2022 19:25:19 +0000

In the last chapter we learned how angular determines who is responsible to provide our dependencies. Today we will explore how once the provider has been determined we can choose what and how we provide our dependencies.

By default when we define a provider token we use the syntax:

providers:[Service]

This in fact is a shorthand version for the following:

providers:[{provide: Service, useClass: Service}]

So what is this provider configuration object? And what properties does it take?

Angular gives us the option to define how we provide our Service.
There are 4 provider definition objects that tell the provider how to create our Service.

Let's review them one by one and when to use them.
We'll begin with the default one:

useClass

With this definition we can choose a specific class to be used as the base to instantiate our service. Taking advantage of the different scopes of the injectors we can use different classes to instantiate the service depending on where we are providing the dependency.

for instance we could do:

In what cases would this be useful?

Let's imagine we are creating a generic MatStepper and we want a different action on the click of the final step depending on which component or module is using that generic stepper. We can provide a StepperService on the component but use a different class to actually implement it so the actions would be different even if we are calling the same service and same method

Another useful case is during testing, sometimes we want a simpler implementation of our service while doing unit tests. In our testbed we can provide the same dependency using a simpler class that satisfies our needs in that test

useExisting

This is somewhat the opposite of useClass. Instead of mapping one token to different classes we are mapping different tokens to the same class. In some way is like using different aliases for the same class

providers:[NewLogger,{provide:OldLogger, useExisting:NewLogger}]

In this example wherever we are injecting the OldLogger we will be using the already existing instance of NewLogger.

This approach can be helpful if we want to replace a legacy service with a new one, whenever replacing the implementations of the legacy service can be too costly.
If in this case we used useClass, we would create two different instances of the same NewLogger

useFactory

There might be some cases where we can't know before hand which implementation of our service should be instanced, because it might be dependent on runtime conditions.

For these cases angular gives us the option to pass a function that will create the service during runtime using parameters known at that moment by the application. This function is called a service factory (hence useFactory)

A typical use case might be that we want to instantiate a service via one class or another depending of user permissions.

It is important to add the deps property when the factory function has other dependencies itself, in this case the LoggerServiceFactory depends on the UserService, so we added it in the deps in its provider object

useValue

When we want to provide constants or configuration parameters in the DI we can use useValue to assign static values to our providers

We'll get more in detail with useValue in the next chapter when we explore what injectionTokens are.

For now we have seen 3 very useful modifiers for our providers and common cases where they might be applicable.

As usual any questions you may have I'll be glad to answer and feel free to follow me to get more updates on my articles.

Thanks!

Angular content projection and SOLID code (ng-content)

Jordi Riera — Tue, 01 Nov 2022 18:46:22 +0000

I remember the first time I was told what content projection was and in particular what ng-content did, my first reaction was: "This makes little sense, why would I waste time resorting to these 'juggler tricks' when I can do the same without these"

But the truth is that content projection is an easy to grasp concept that can help you write better code and follow SOLID principles while developing in angular.

What is content projection

Content projection in angular is the possibility to take whatever is between a component's tags and have that content show inside the very same component.

I know what you are thinking, why bother doing it this way when you can do it manually without much effort.
To illustrate the advantages of content projection I'll use one application that uses a card to display some diverse information inside of it.

On the first component I will use an approach without content projection. On the other I will use content projection

Absence of content projection

Normally without content projection we could use an approach similar to this one:

We use ngIf to determine what content gets displayed depending on an input property value, and if it needs to escalate we would use ngSwitch for each and every option that was necessary to display.

This approach has short legs because sooner or later the component gets packed with ngSwitch/Cases and loses readability.

But not only that, if later on the specifications change and the card needs new sections or different looks you are modifying the same component, which now probably holds a few more lines of code due to the different ngSwitch so the maintainability of the code suffers.

This would trigger in my mind a warning of potential single responsibility principle failure. We are mixing the Card UI display with the content choices responsibility.
Also with this approach if we need to extend the functionality of this component with different content options we are forced to modify its source code, so we are breaking the open-closed SOLID principle

With content projection

Using angular content projection the approach to follow would be something on these lines:

and used in the following way:

So we have one simple generic card component that only cares about how the card looks and behaves, and we have separate components or elements in charge of the content and their implementations do not interfere

If we compare this approach to the previous one, I think the advantages start to become obvious. The separation of concerns between the card UI and its contents is clear and well defined and any extension of contents doesn't imply changing the card component itself. And the same the other way around, the need to adjust how the card UI looks and acts does not interfere in the definition and implementation of its contents.

This way we have a code that is clearer to maintain and less error prone due to the modularity of the concepts and responsibilities, plus we increase the reusability of our code in a great deal

Summary

With content projection we can achieve a greater modularity of our code and increased reusability since we can create generic components that can be extended as needed throughout our application without the need to modify their source code.

Also this complies with two SOLID principles:
Open-closed principle and Single responsibility principle

So all in all this easy to learn angular feature can help us in our everyday code and be better programmers

Also if you want to check out this application I have a basic implementation of this on Stackblitz

Angular Dependency Injection Understood II

Jordi Riera — Tue, 25 Oct 2022 15:56:05 +0000

So in the first chapter of the series we had a general look at what dependency injection is, how it works and why we use it.
We mentioned that there were 3 elements in the pattern: Client, Service and Injector.

In today's chapter I will talk about the Injectors and their role in dependency injection in angular. So let's get started!

Angular Injector:

I am sure that if you have used dependency injection in angular you have seen the following patterns:

But when should we use on or the other?
In order to understand when and why to use one or the other we need to explore two important concepts:

Injector Hierarchy
Dependency resolution

Injector Hierarchy

Angular has two main injector hierarchies that govern which injector is the responsible to provide the dependency to the requesting Client
These hierarchies are the ModuleInjector and the ElementInjector

ElementInjector

When we provide a dependency using the @Component() or @Directive() providers we are making that dependency available for that component or directive and all its children (example 2 above) and we are inside the ElementInjector hierarchy.
It's interesting to note that for each component instance that holds that provider definition we are creating a new instance of the dependency

ModuleInjector

Whenever we provide the dependency inside the @Injectable() decorator. (example 1 above) or inside an NgModule's Providers array we are inside the ModuleInjector hierarchy.
In ModuleInjector the hierarchy is not dependant on any children rather it is a quite well defined hierarchy composed of three injectors:

1 root ModuleInjector

@Injectable({providedIn:'root'})

2 platform ModuleInjector

@Injectable({providedIn:'platform'})

3 NullInjector

And finally, when is the NullInjector reached and what does it do? In this case the answer is quite simple, when angular doesn't find the provider for a dependency anywhere it will reach the NullInjector which is the responsible to throw the

NullInjectorError: No provider for dependency

And this takes us to dependency resolution and how does angular traverse the different injectors and determines which Injector should be responsible to provide the dependency

Dependency Resolution

According to angular official documentation angular determines how to resolve a dependency the following way:

Against its parents in the ElementInjector hierarchy.
Against its parents in the ModuleInjector hierarchy.

But what does that actually mean?
What angular does when a dependency is injected in a component or directive is try to search firstly inside its ElementInjector, that is in its own providers and its ancestor components providers.
Only then if angular can not find any provider in the ElementInjector, it starts looking in its ModuleInjector going to the root and then the platform injectors and finally reaching the NullInjector which will throw the error we see when we forget to define a provider for our dependency

So this is the default way angular resolves dependencies, there are some other concepts here but we will see them in another chapter of this series

Summing up

So we have seen that we have two main injector hierarchies in angular:

ElementInjector
ModuleInjector

And we have seen how we can provide in one or the other hierarchy of Injectors
We have also learned that angular will traverse all the ElementInjector hierarchy before moving on to the ModuleInjector hierarchy which will end in the NullInjector if no provider is found.

I hope this helps to clarify when we should provide our dependencies in one way or another and the differences and advantages we can get from it.
If you have any questions regarding this, I will do my best to provide an answer to them.

See you on the next chapter!

Angular Dependency Injection Understood I - No needles involved, no worries

Jordi Riera — Sun, 16 Oct 2022 17:27:46 +0000

Understanding what dependency injection is outside of angular (DI onwards in the article) will help us gain a broader perspective of how it works and provide us knowledge on why it is important and how to leverage it inside angular, so the first question is:

What is dependency injection?

DI is in fact a programming design pattern in object oriented languages that allows classes to use dependencies without needing to know anything about them. It aims at a greater separation of concerns, decoupling the link between client class and the dependency.

For instance, normally in an OOP language such as Typescript one would pass dependencies the following way:

Traditional dependency instantiation

Basically the class (client) would need to instantiate the new object (service) with the keyword new with all the properties the new object constructor would need, so the service is hard coded inside the client, creating a tighter coupling between the two classes.

However using DI the dependency the client does not build the service itself, it only needs to declare the interfaces of the services it uses

Dependency Injection

Enter the Injector

The heavy lifting in DI is done by an object called injector who is the responsible to provide the new object to the receiving class and keep track of the object graph and each objects implementations.

This pattern allows for greater modularity and code reusability since each class worries only of itself and not so much about how its dependencies are constructed

What about angular?

Since we know that in angular we aim to create code that is very reusable and modular it makes total sense that the angular team opted in for this design pattern as it supports this vision of modular and reusable components code.

Angular also uses injectors to provide the dependencies, actually the providedIn:'root' that we normally see in services is referencing to the root injector, which takes care of dependencies that need to be available in the whole application.

We'll see more about that in the next chapters of this series about dependency injection. For now a small recap:

Takeaways

Dependency injection is a design pattern that aims to have greater code reusability and modularity
There are 3 main actors in this design: Client, Service and Injector
The design fits perfectly in angular where client, service and injector are integrated within the framework in order to enhance the modularisation and reusability of its elements (services, components, directives and pipes)