C'est exactement le problème que résout rxMethod, une fonction fournie par le package @ngrx/signals/rxjs-interop.

Elle ne remplace pas RxJS, elle le fait cohabiter proprement avec les signaux.

Le problème qu'elle résout

Avant rxMethod, connecter un flux RxJS à un signal demandait souvent du bricolage : un effect() qui souscrit manuellement à un Observable, une gestion artisanale du désabonnement, et le risque bien réel de fuites mémoire ou de traitements en double si l'on n'y prête pas attention.

Voici un exemple représentatif de ce qu'on écrivait "avant" :

import { Component, effect, inject, signal, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';

@Component({ /* ... */ })
export class TodoList implements OnDestroy {
  #todosService = inject(TodosService);
  #subscription?: Subscription;

  userId = signal(1);
  todos = signal<Todo[]>([]);

  constructor() {
    effect(() => {
      const id = this.userId(); // lecture du signal → dépendance déclarée

      // ⚠️ On souscrit manuellement à chaque exécution de l'effect
      this.#subscription = this.#todosService.getByUserId(id).subscribe({
        next: (todos) => this.todos.set(todos),
        error: (err) => console.error(err),
      });
    });
  }

  ngOnDestroy() {
    this.#subscription?.unsubscribe();
  }
}

Ce code a deux défauts typiques :

• fuite mémoire / traitements en double : à chaque changement de userId, l'effect relance une souscription, mais n'annule jamais la précédente. Si l'utilisateur change rapidement d'identifiant, plusieurs requêtes HTTP restent actives en parallèle, et rien ne garantit que les réponses arrivent dans l'ordre. Ainsi, la plus ancienne peut très bien écraser la plus récente.

• nettoyage fragile : on ne désabonne qu'à la destruction du composant (ngOnDestroy), pas entre deux exécutions de l'effect. Pour corriger ça "à la main", il faudrait gérer soi-même l'ancienne souscription via le onCleanup de l'effect :

effect((onCleanup) => {
  const id = this.userId();

  const sub = this.#todosService.getByUserId(id).subscribe({
    next: (todos) => this.todos.set(todos),
  });

  onCleanup(() => sub.unsubscribe());
});

rxResource, la réponse native d'Angular à ce problème

Face à ce genre de bricolage, Angular propose désormais sa propre solution native pour la lecture de données asynchrones : rxResource, dans @angular/core/rxjs-interop.

Elle résout exactement le problème illustré ci-dessus, sans effect(), sans Subscription manuelle, sans onCleanup :

import { Component, signal, inject } from '@angular/core';
import { rxResource } from '@angular/core/rxjs-interop';

@Component({ /* ... */ })
export class TodoList {
  #todosService = inject(TodosService);
  userId = signal(1);

  todosResource = rxResource({
    params: () => ({ userId: this.userId() }),
    stream: ({ params }) => this.#todosService.getByUserId(params.userId),
  });
}

rxResource gère lui-même l'état complet de la requête :

• valeur : todosResource.value() ;

• chargement : todosResource.isLoading() ;

• erreur : todosResource.error() ;

• l'annulation automatique de la requête précédente à chaque changement de params sans qu'on ait à écrire le moindre switchMap ni à se soucier du désabonnement.

Sur ce cas d'usage précis, une lecture pilotée par un paramètre réactif est bien évidemment plus simple qu'un rxMethod.

Alors, rxResource rend-il rxMethod inutile ?

Pas tout à fait, et c'est ce que la suite de cet article va démontrer.

Anatomie de rxMethod

import { rxMethod } from '@ngrx/signals/rxjs-interop';

function rxMethod<Input>(
  generator: (source$: Observable<Input>) => Observable<unknown>,
  config?: { injector?: Injector }
): RxMethod<Input>

rxMethod prend en paramètre un générateur qui n'est rien d'autre qu'une fonction qui reçoit un flux (Observable<Input>) et retourne un Observable transformé, typiquement via un pipe().

Le paramètre de type Input fixe le type des données attendues en entrée, indépendamment de la forme sous laquelle l'appelant les fournit.

import { Component, inject, signal } from '@angular/core';
import { rxMethod } from '@ngrx/signals/rxjs-interop';
import { switchMap } from 'rxjs';
import { tapResponse } from '@ngrx/operators';

@Component({ /* ... */ })
export class TodoList {
  readonly #todosService = inject(TodosService);
  readonly userId = signal(1);
  readonly todos = signal<Todo[]>([]);

  readonly loadTodos = rxMethod<number>(
    switchMap((id) =>
      this.#todosService.getByUserId(id).pipe(
        tapResponse({
          next: (todos) => this.todos.set(todos),
          error: console.error,
        })
      )
    )
  );

  constructor() {
    this.loadTodos(this.userId);   // un Signal<number>
    this.loadTodos(this.userId$);  // un Observable<number>
    this.loadTodos(1);            // une valeur brute, number
  }
}

Trois façons d'appeler loadTodos sont possibles :

• si c'est un Signal, il crée un effect() interne qui pousse la valeur courante du signal dans le flux source à chaque changement ;

• si c'est un Observable, il s'y abonne directement et transmet chaque valeur émise dans le flux source ;

• si c'est une valeur statique, il l'émet une seule fois dans le flux source, immédiatement.

La logique métier ne change pas, seule la source d'entrée varie. Dans les trois cas, la valeur finit par arriver, sous forme de number.

Pourquoi le choix de l'opérateur de flattening compte

rxMethod ne dicte aucun opérateur d'aplatissement particulier : c'est à vous de choisir entre switchMap, mergeMap, concatMap ou exhaustMap selon le comportement de concurrence souhaité.

• switchMap : annule la requête précédente dès qu'une nouvelle arrive. C'est idéal pour une recherche ou un chargement de détail par identifiant.

• concatMap : traite les requêtes dans l'ordre, une par une. Il est utile pour des écritures séquentielles.

• mergeMap : lance tout en parallèle pour des opérations indépendantes.

• exhaustMap : ignore les nouvelles requêtes tant que la précédente n'est pas terminée. C'est très pratique pour éviter les doubles soumissions.

Ce choix a un impact direct sur la fiabilité de l'application, notamment pour éviter les fameuses "race conditions" où une réponse arrivée en retard écrase un résultat plus récent.

Le contexte d'injection

rxMethod doit, par défaut, être appelée dans un contexte d'injection Angular (constructeur, champ de classe, ou tout endroit où inject() est disponible). Si ce n'est pas possible, on peut fournir explicitement un Injector :

constructor() {
  this.loadTodos = rxMethod<number>(
    switchMap((id) => /* ... */),
    { injector: this.injector }
  );
}

Cette contrainte garantit que le cycle de vie de la souscription est correctement rattaché, et donc automatiquement nettoyé à la destruction du composant.

Plus besoin de gérer manuellement un Subscription et son unsubscribe().

Les mutations : là où rxResource montre ses limites

rxResource a un modèle mental très clair : une fonction stream qui se relance automatiquement chaque fois que params() produit une nouvelle valeur.

C'est un peu comme une requête qu'on rejoue à chaque changement de paramètre. C'est excellent pour du GET.

Cependant, voyons ce qui se passe si on essaie de le détourner pour une mutation.

// ⚠️ Détournement de rxResource pour une sauvegarde - à éviter
export class TodoEditor {
  #todosService = inject(TodosService);
  todoToSave = signal<Todo | null>(null);

  saveResource = rxResource({
    params: () => this.todoToSave(),
    stream: ({ params }) => {
      if (!params) return of(undefined);
      return this.#todosService.save(params);
    },
  });

  onSubmit(todo: Todo) {
    this.todoToSave.set(todo); // 👈 on force la mutation via un changement de "requête"
  }
}

Trois problèmes concrets apparaissent immédiatement :

• la déduplication casse le renvoi : rxResource ne relance stream que lorsque params() change de valeur. Si l'utilisateur soumet deux fois le même formulaire (même objet todo), le second clic ne déclenche rien du tout : params() n'a pas changé, donc la mutation n'est jamais rejouée. C'est un comportement correct pour une lecture, mais un bug silencieux pour une écriture.

• l'annulation implicite est dangereuse : si todoToSave() change une nouvelle fois pendant qu'une sauvegarde précédente est encore en cours, le comportement de type switchMap de rxResource annule la requête HTTP en cours. Pour une lecture, perdre une réponse obsolète est sans conséquence. Pour une écriture, cela peut vouloir dire qu'une sauvegarde en base de données est interrompue au milieu de son exécution.

• aucun contrôle sur la concurrence : impossible de dire à rxResource "ignore les nouveaux appels tant que le précédent n'est pas terminé" (exhaustMap) ou "empile-les dans l'ordre" (concatMap). Le modèle est figé sur un comportement proche de switchMap, pensé pour représenter un état, pas une suite d'événements.

Voyons maintenant la même mutation avec rxMethod :

export class TodoEditor {
  #todosService = inject(TodosService);
  saving = signal(false);

  saveTodo = rxMethod<Todo>(
    exhaustMap((todo) => {
      this.saving.set(true);
      return this.#todosService.save(todo).pipe(
        tapResponse({
          next: () => this.saving.set(false),
          error: (err) => {
            console.error(err);
            this.saving.set(false);
          },
        })
      );
    })
  );

  onSubmit(todo: Todo) {
    this.saveTodo(todo); // 👈 chaque appel est un événement, pas une valeur d'état
  }
}

Ici, tout fonctionne comme attendu :

• chaque appel à saveTodo(todo) déclenche systématiquement un envoi, même avec un todo identique au précédent. rxMethod alimente en interne un flux d'événements (proche d'un Subject) : il ne compare pas les valeurs, il les pousse. Rien n'est dédupliqué.

• exhaustMap protège explicitement contre le double clic : tant qu'une sauvegarde est en cours, les appels suivants sont ignorés. Un choix assumé, contrairement au comportement implicite et non paramétrable de rxResource.

• aucune sauvegarde en cours n'est jamais annulée involontairement, puisque rien ne force rxMethod à réagir à un changement de "paramètre" : c'est l'appel explicite qui déclenche l'action.

La différence de fond tient en une phrase : rxResource modélise un état (une donnée dérivée d'un paramètre, qu'on relit), rxMethod modélise un flux d'événements (une action qu'on déclenche).

Vouloir faire des mutations avec le premier revient à forcer un modèle déclaratif à se comporter comme un modèle impératif. Ça fonctionne parfois en apparence, mais les cas limites (double soumission, annulation, ordre d'exécution) finissent toujours par se rappeler à vous.

Une bonne règle de partage des rôles :

Les deux ne s'excluent pas : il est courant de voir rxResource pour l'affichage et rxMethod pour les mutations coexister dans le même composant.

Au-delà des cas de lecture

Rien n'empêche non plus d'utiliser rxMethod pour des appels HTTP simples, sans structure d'état complexe autour :

export class UserListComponent {
  #http = inject(HttpClient);
  users = signal<User[]>([]);

  loadUsers = rxMethod<void>(() =>
    this.#http.get<User[]>('/api/users').pipe(
      tap((data) => this.users.set(data))
    )
  );
}

C'est une alternative intéressante aux appels RxJS "à la main" dans un effect(), avec une API plus explicite sur ce qui déclenche réellement l'effet de bord.

En somme, rxMethod n'est pas un remplaçant de RxJS, ni un concurrent des signaux. Il joue un rôle de pont. Il permet de :

• conserver la richesse des opérateurs RxJS (debounce, annulation, combinaison de flux) ;

• s'intégrer nativement aux signaux Angular, sans code de liaison superflu ;

• automatiser la gestion du cycle de vie des souscriptions ;

• accepter indifféremment une valeur, un signal ou un observable en entrée ;

• couvrir les mutations là où rxResource, pensé pour la lecture, montre ses limites.

Pour toute équipe qui migre progressivement vers les signaux tout en gardant des flux de données complexes basés sur RxJS, rxMethod constitue aujourd'hui l'un des outils les plus pragmatiques de l'écosystème NgRx, particulièrement complémentaire de rxResource pour tout ce qui touche à l'écriture plutôt qu'à la lecture.

Pour plus d'informations 👉🏽 rxMethod

👉 Le Problème : La Magie de Zone.js

Pour comprendre le Zoneless, il faut d'abord saisir le rôle de Zone.js, le compagnon silencieux d'Angular depuis ses débuts.

Zone.js est une bibliothèque qui “patch” le moteur d'exécution JavaScript dans le navigateur. Son objectif principal est de détecter quand des changements pourraient se produire dans votre application. Comment fait-il ça ? En interceptant les événements asynchrones courants :

• Timers (setTimeout, setInterval) ;

• Requêtes HTTP (fetch, XMLHttpRequest) ;

• Événements du DOM (clics, saisies, etc.) ;

• Promesses (Promise.then, async/await).

Chaque fois qu'une de ces opérations se termine, Zone.js notifie Angular qu'un "tick" s'est produit. Angular, à son tour, déclenche son mécanisme de détection de changement pour s'assurer que l'interface utilisateur reflète le nouvel état de vos données.

C'est ce qui donne à Angular sa réactivité "magique" : vous modifiez une variable, et l'affichage se met à jour sans que vous ayez à le dire explicitement.

Cependant, cette magie a un coût : la performance. Chaque détection de changement initiée par Zone.js doit parcourir l'arbre des composants pour vérifier les potentielles mises à jour. Dans les grandes applications complexes, avec de nombreux événements asynchrones, cela peut entraîner des cycles de détection de changement inutiles et coûteux, ralentissant l'application et impactant l'expérience utilisateur.

👉 La Solution : Le Zoneless ou le Contrôle Manuel

Le terme Zoneless fait référence à la possibilité de faire fonctionner une application Angular sans Zone.js, ou du moins en réduisant considérablement sa portée. L'idée n'est pas de se débarrasser complètement de la détection de changement, mais de la rendre plus explicite et optimisée.

Au lieu que Zone.js nous dise quand un changement a potentiellement eu lieu, le développeur prend le contrôle et signale explicitement à Angular quand il doit vérifier les changements.

Comment cela fonctionne-t-il concrètement ? Principalement grâce aux Signals (Signaux).

👉 Le Rôle Central des Signals

Les Signals sont une nouvelle primitive de réactivité introduite dans Angular 16 (et améliorée dans les versions suivantes).

Lorsque vous utilisez des Signals, Angular sait exactement quels composants dépendent de quelles données. Si vous modifiez un Signal, Angular ne mettra à jour que les composants (et les parties de ces composants) qui sont directement affectés par ce Signal. Cela contraste fortement avec l'approche de Zone.js qui vérifie l'ensemble de l'application ou de grandes parties de celle-ci.

En mode Zoneless, c'est la modification d'un Signal qui devient le déclencheur principal de la détection de changement, et non plus un événement asynchrone arbitraire intercepté par Zone.js.

Angular aura besoin de déclencher une détection de changement en mode Zoneless :

• Quand un Signal est mis à jour.

• Quand un événement DOM se produit (comme un clic), Angular peut toujours les détecter.

• Quand vous utilisez markForCheck() sur un ChangeDetectorRef (pour les cas où vous ne travaillez pas avec des Signals ou avez des données asynchrones non basées sur des Signals).

En somme, le Zoneless n'est pas un mystère insaisissable, mais une évolution logique de la stratégie de détection de changement d'Angular. En s'appuyant sur les Signals, Angular nous offre la possibilité de reprendre le contrôle sur la réactivité de nos applications, menant à des performances accrues, un code plus prévisible et une expérience de développement améliorée.

Pour plus d'informations 👉 Zoneless

Avant d’entrer dans le vif du sujet, nous rappellerons, l’utilisation classique de la méthode patchValue(…) sur un formulaire simple. Considérons, le bout de code suivant où nous avons un composant ProfileEditorComponent dans lequel est implémenté un formulaire simple composé de deux champs à savoir firstName et lastName :

import {Component} from '@angular/core';
import {FormGroup, FormControl} from '@angular/forms';

@Component({
  selector: 'app-profile-editor',
  templateUrl: './profile-editor.component.html',
  styleUrls: ['./profile-editor.component.css'],
  standalone: true,
})

export class ProfileEditorComponent {
  profileForm = new FormGroup({
    firstName: new FormControl(''),
    lastName: new FormControl('')
  });
}

Dans l’exemple susmentionné, pour mettre à jour les valeurs de notre formulaire en utilisant patchValue(…), voici ce que nous faisons :

this.profileForm.patchValue({
    firstName: 'John',
    lastName: 'Doe'
});

Une fois, ce bout de code exécuté, notre formulaire sera mis à jour avec les valeurs John pour le firstName et Doe pour le lastName.

La question qui vient à l’esprit est la suivante ?

Est-ce aussi le cas lorsque nous faisons face à un formulaire qui contient des contrôles de type FormArray ?

La meilleure façon de s’en assurer, est de faire l’expérience. Let’s go !

Considérons le code ci-dessous :

import { Component } from '@angular/core';
import { FormBuilder, FormArray, FormGroup } from '@angular/forms';

@Component({
  selector: 'app-addresses',
  template: `
    <form [formGroup]="addressesForm">
      <div formArrayName="addresses">
        <div *ngFor="let address of addresses.controls; let i = index" [formGroupName]="i">
          <input type="text" formControlName="road" placeholder="Road">
          <input type="text" formControlName="city" placeholder="City">
        </div>
        <button type="button" (click)="addAddress()">Add an address</button>
      </div>
    </form>
  `
})
export class AddressesComponent {
  addressesForm = new FormGroup({
   addresses: new FormArray([
      new FormGroup({
        road: new FormControl(),
        city: new FormControl()
      })
   ])
 });

  public get addressesFormArray() {
    return this.addressForm.get('addresses');
 }
}

Dans le code ci-dessus, nous avons un formulaire qui contient un contrôle de type FormArray. Supposons, qu’après un traitement, nous voulons mettre à jour les adresses de notre formulaire en utilisant naturellement notre méthode patchValue(…). Voici ce que nous écrirons :

this.addressesFormArray.patchValue([
    {
        road: '1',
        city: 'Paris'
    },
    {
        road: '2',
        city: 'Lyon'
    },
    {
        road: '3',
        city: 'Marseille'
    }
]);

Dans notre exemple, si l’on se confère à la logique de la méthode patchValue(…), normalement, notre formulaire doit être mis à jour avec les valeurs des adresses indiquées.

Malheureusement, je ne suis navré de vous décevoir mais ce n’est pas le cas !

Lorsqu’on se rend sur l’interface web, on se rend compte que c’est uniquement le premier objet du tableau des adresses qui est conservé comme valeur.

Notre méthode patchValue(…) n’a pas su itérer sur le reste des éléments et c’est là tout le piège !

Pour résoudre ce problème, une gymnastique s’impose à nous lors de l’utilisation de notre méthode patchValue(…). Voici donc comment procéder étape par étape :

Étape 1 : Nettoyer notre FormArray

this.addressesFormArray.clear();

Étape 2 : Recréer une nouvelle instance de notre FormArray

/*
    Considérons une variable `myAddresses` qui contient toutes les adresses récupérées 
    après un appel d'API par exemple
*/

while (this.addressesFormArray.controls.length < myAddresses.length) {
   this.addressesFormArray.push(new FormGroup({
        road: new FormControl(),
        city: new FormControl()
    }));
}

Étape 3 : Mettre à jour les valeurs avec patchValue(…)

this.addressesFormArray.patchValue(myAddresses);

En somme, pour appliquer un patchValue(…) sur notre formulaire, il est crucial d’identifier la nature des contrôles. S’agit t-il d’un FormControl classique ou d’un FormArray conduisant à un formulaire complexe ? Suivant, le cas, nous savons aujourd’hui quoi faire.

Pour plus d'informations 👉 Reactive Forms

Avant d’entrer dans le vif du sujet, nous essaierons de comprendre ce qu’est le cycle de vie d’un composant.

Le cycle de vie d’un composant en général, peu importe la technologie utilisée représente les différentes étapes par lesquelles le composant passe depuis la création jusqu’à la destruction. En effet, ce processus est très similaire à la vie d’un être humain par exemple. L’homme naît, grandit, vieillit et meurt. C’est comme cela, il faut voir le cycle de vie d’un composant également. En Angular, ces différentes phases sont perceptibles à travers les différentes méthodes que le framework nous offre. Le cycle de vie d'un composant est étroitement lié à la façon dont Angular vérifie les modifications apportées à nos composants au fil du temps. Notre prochain objectif sera décortiquer une à une ces méthodes afin de rendre le plus accessible possible à la compréhension des uns et des autres.

1. La méthode constructor() :

Le framework Angular est basé sur le langage TypeScript. Chaque composant Angular n’est rien d’autre qu’une classe TypeScript. Lorsqu’on parle de classe, on parle de la programmation orientée objet. Ainsi, la première méthode qui s’exécute dans une classe c’est le constructeur de la classe qui est constructor.

Dès que le framework Angular crée une instance de notre composant à l’exécution de notre application, c’est la méthode constructor qui s’exécute en premier. On appelle cette étape du cycle de vie d’un composant Angular : création.

2. La méthode ngOnChanges() :

Après la phase de création que nous venons de voir précédemment, la prochaine étape c’est la phase : détection de changements (change detection en anglais). La première méthode de cette phase est la méthode ngOnChanges().

La méthode ngOnChanges s'exécute après que les entrées du composant ont été modifiées. En effet, pour jauger de la pertinence de cette méthode et comprendre comment elle fonctionne, il faut la tester sur un composant ayant des inputs.

En Angular, lorsqu’on décide de passer des informations d’un composant A parent vers un composant B enfant, on passe par des inputs au niveau du composant enfant. Lorsque le composant parent A met à jour les inputs du composant enfant B, la méthode ngOnChanges() se déclenche et ce à chaque nouvelle mise à jour des inputs .

3. La méthode ngOnInit() :

La deuxième méthode de la phase de détection de changement du cycle de vie d’un composant Angular est la méthode ngOnInit().

La méthode ngOnInit() s'exécute après qu'Angular ait initialisé toutes les entrées (inputs) des composants avec leurs valeurs initiales. La méthode ngOnInit() d'un composant s'exécute exactement une fois.

Cette étape se produit avant que le template HTML du composant ne soit initialisé. Cela signifie que vous pouvez mettre à jour l'état du composant en fonction de ses valeurs d'entrée (input) initiales.

4. La méthode ngDoCheck()

Juste après l’exécution de la méthode ngOnInit(), notre composant demeure toujours dans la phase de détection de changement à travers l’exécution de la méthode ngDoCheck() .

La première fois que la méthode ngDoCheck() s’exécute c’est juste après l’exécution de la méthode ngOnInit(). Ensuite, ngDoCheck() s'exécute avant chaque vérification par Angular des changements apportés au niveau du template HTML de notre composant.

Cette méthode s'exécute très fréquemment et peut avoir un impact significatif sur les performances de votre page. Ainsi, évitons d’utiliser cette méthode autant que possible, ne l'utilisons que lorsque nous n’avons vraiment pas d'autre alternative.

5. La méthode ngAfterContentInit()

Lorsque dans notre composant Angular, nous interagissons avec des content queries à savoir @ContentChild() ou @ContentChildren() , la méthode ngAfterContentInit() s'exécute une seule fois lorsque tous les enfants imbriqués (content queries) dans le composant ont été initialisés.

Nous pouvons donc accéder à l'état initialisé de nos queries mais toute tentative de modification de l'état dans cette méthode entraîne une erreur ExpressionChangedAfterItHasBeenCheckedError.

La méthode ngAfertContentInit() lorsqu’elle est définie, s’exécute juste après le ngDoCheck() .

Pour ceux qui n’ont aucune idée de ce qu’est une content query, voici un exemple :

@Component({
  selector: 'custom-toggle',
  ...
  template: `<div> 
             <ng-content></ng-content> 
             </div>`
})
export class CustomToggle {
  text: string;
}
@Component({
  selector: 'custom-expando',
  ...
  template: `<div> 
             <ng-content></ng-content> 
             </div>`
})
export class CustomExpando {
  @ContentChild(CustomToggle) toggle: CustomToggle;
  ngAfterContentInit() {
    console.log(this.toggle.text);
  }
}
@Component({
  selector: 'user-profile',
  template: `
    <custom-expando>
      <custom-toggle>Show</custom-toggle>
    </custom-expando>
  `
})
export class UserProfile { }

Le composant custom-toggle est projecté dans le composant custom-expando à travers la directive ng-content.

Le composant custom-toggle à son tour est capable de projecter du contenu d’où le texte Show à l’intérieur des balises custom-toggle lors de son utilisation dans le template du composant user-profile.

Lorsqu’on parle de content query, il faut penser à la projection de contenue avec la directive ng-content.

6. La méthode ngAfterContentChecked() :

La méthode ngAfterContentChecked() est étroitement liée à la méthode ngAfterContentInit(). En effet, lorsque toutes nos content queries sont initialisées, la méthode ngAfterContentChecked() s’exécute pour marquer ces content queries comme étant checked. Cela signifie tout simplement que ces content queries ont été vérifiées pour déterminer si des changements ont eu lieu à leurs différents niveaux.

Cette méthode s'exécute très fréquemment et peut avoir un impact significatif sur les performances de votre page. Ainsi, évitons d’utiliser cette méthode autant que possible, ne l'utilisons que lorsque nous n’avons vraiment pas d'autre alternative.

Bien que nous puissions accéder à l'état mis à jour des content queries ici, toute tentative de modification d'un état dans cette méthode entraîne une erreur ExpressionChangedAfterItHasBeenCheckedError (ExpressionChangedAfterItBeenChecked).

7. La méthode ngAfterViewInit() :

Tout comme nous l’avons vu précédemment avec la méthode ngAfterContentInit() , la méthode ngAferViewInit() aussi s’exécute juste après la méthode ngDoCheck() .

En effet, pendant que la méthode ngAfterContentInit() est utilisée pour les content queries , la méthode ngAfterViewInit() est utilisée pour les view queries (@ViewChild() , @ViewChildren().

La méthode ngAfterViewInit() s'exécute une seule fois lorsque tous les enfants imbriqués (view queries) dans le composant ont été initialisés.

Nous pouvons donc accéder à l'état initialisé de nos view queries mais toute tentative de modification de l'état dans cette méthode entraîne une erreur ExpressionChangedAfterItHasBeenCheckedError.

Pour ceux qui n’ont aucune idée de ce qu’est une view query, voici un exemple :

@Component({
  selector: 'custom-card-header',
  ...
})
export class CustomCardHeader {
  text: string;
}
@Component({
  selector: 'custom-card',
  template: '<custom-card-header>Visit sunny California!</custom-card-header>',
})
export class CustomCard {
  @ViewChild(CustomCardHeader) header: CustomCardHeader;
  ngAfterViewInit() {
    console.log(this.header.text);
  }
}

Dans le composant parent CustomCard, on essaie de récupérer le composant enfant CustomCardHeader.

Lorsqu’on parle de view query, il faut penser à un composant enfant qu’on essaie de récupérer depuis un composant parent dynamiquement.

8. La méthode ngAfterViewChecked() :

La méthode ngAfterViewChecked() suit la même logique que la méthode ngAfterContentChecked() . Tout comme la méthode ngAfterContentChecked() est étroitement liée à la méthode ngAfterContentInit() , la méthode ngAfterViewChecked() est aussi liée à la méthode ngAfterViewInit() .

En effet, lorsque toutes nos view queries sont initialisées, la méthode ngAfterViewChecked() s’exécute pour marquer ces view queries comment étant checked. Cela signifie tout simplement que ces view queries ont été vérifiées pour déterminer si des changements ont eu lieu à leurs différents niveaux.

Bien que nous puissions accéder à l'état mis à jour des view queries ici, toute tentative de modification d'un état dans cette méthode entraîne une erreur ExpressionChangedAfterItHasBeenCheckedError (ExpressionChangedAfterItBeenChecked).

9. Les méthodes afterRender() et afterNextRender():

Les méthodes afterNextRender() et afterRender() font parties des nouvelles méthodes ajoutées au cycle de vie d’un composant Angular depuis la version 16.2 du framework.

La méthode afterRender() se déclenche à chaque fois que tous les composants sont chargés dans le DOM*.*

Quant à la méthode afterNextRender(), elle se déclenchera la prochaine fois que tous les composants seront chargés dans le DOM mais une seule fois*.*

10. La méthode ngOnDestroy() :

La méthode ngOnDestroy s'exécute une fois juste avant la destruction d'un composant. Angular détruit un composant lorsqu'il n'est plus affiché sur la page, par exemple lorsqu'il est masqué par un NgIf ou lorsqu'on navigue vers une autre page.

En somme, le cycle de vie d’un composant Angular se résume en trois phase à savoir : la phase de création, la phase de détection de changements et le rendering. La phase de rendering a été introduite dans le framework à la sortie de la version 16 du framework. Chacune de ces phases fait appel à des méthodes dans lesquelles nous pouvons gérer des traitements au besoin. Il est très important de maîtriser ces phases afin d’assurer la performance de nos composants Angular.

Pour plus d'informations 👉 Component Lifecycle

Dans ce nouvel article, nous verrons ensemble un nouveau type de input qui est toujours basé sur Angular Signal. Ce nouveau type de input a été conçu de façon très ingénieuse et est aussi très similaire à une fonctionnalité existante de Angular qui est très utilisée. Découvrons-le ensemble sans plus attendre !

Qu'est-ce qu'un Model Input en Angular ?

En nous basant sur la documentation de Angular, un Model Input est un type spécial d'input qui permet à un composant A de propager de nouvelles valeurs vers un composant B. En effet, lorsqu'on analyse cette définition, ce qui nous vient à l'esprit c'est qu'un Model Input fait la même chose qu'un Signal Input dans le fonctionnement comme l'indique cet exemple :

import {Component, model, input} from '@angular/core';
@Component({...})
export class CustomCheckbox {
  // This is a model input.
  checked = model(false);

  // This is a standard input.
  disabled = input(false);
}

<!--- Parent component side --->
<custom-checkbox [checked]="true" [disabled]="false" />

Le code ci-dessus nous démontre que les deux types d'input à savoir Signal Input et Model Input permettent de faire le one-way binding c'est-à-dire dans notre cas ici la communication unidirectionnelle d'un composant parent vers un composant enfant et non l'inverse.

Cependant, le Model Input ne se limite pas à cela. Dans sa philosophie de propager de nouvelles valeurs, le Model Input est également accessible en écriture contrairement à un Signal Input. Nous pouvons donc modifier la valeur d'un Model Input depuis le composant enfant où il a été instancié ce qui n'est pas le cas du Signal Input qui est read-only. Voici une illustration :

import {Component, model, input} from '@angular/core';
@Component({
  selector: 'custom-checkbox',
  template: '<div (click)="toggle()"> ... </div>',
})
export class CustomCheckbox {
  checked = model(false);
  disabled = input(false);

  toggle() {
    // While standard inputs are read-only, you can write directly to model inputs.
    this.checked.set(!this.checked());
  }
}

Dans l'illustration de code ci-dessus, nous remarquons l'utilisation de la méthode set() sur notre Model Input. Nous pouvons en déduire que la méthode update() aussi peut être utilisée et pour conclure que notre Model Input est un WritableSignal.

Pour finir, en nous basant sur les deux extraits de code précédent, on peut facilement émettre l'hypothèse suivante :

Lorsque le composant parent ou enfant (peu importe l'un des deux) écrit une nouvelle valeur dans le Model Input, Angular peut propager cette nouvelle valeur vers le composant qui lie cette valeur.

En effet, c'est typiquement le fonctionnement du Model Input. Il ne permet pas que la liaison unidirectionnelle (one-way binding) mais également la liaison bidirectionnelle (two-way binding). Tout ceci nous fait penser à ngModel que nous utilisons déjà énormément dans Angular.

Two-way binding avec Model Input

La documentation de Angular nous présente deux situations différentes pour l'utilisation du two-way binding en se basant sur Angular Signal ou sur du JS/TS classique.

• Two-way binding avec du JS/TS classique :

@Component({
  ...,
  // `checked` is a model input.
  // The parenthesis-inside-square-brackets syntax (aka "banana-in-a-box") creates a two-way binding
  template: '<custom-checkbox [(checked)]="isAdmin" />',
})

export class UserProfile {
  protected isAdmin = false;
}

Dans l'exemple ci-dessus, le composant CustomCheckbox peut écrire des valeurs dans checked, qui propage ensuite ces valeurs vers la propriété isAdmin dans UserProfile. Cette liaison permet de synchroniser les valeurs de checked et de isAdmin.

• Two-way binding avec Angular Signal :

@Component({
  ...,
  // `checked` is a model input.
  // The parenthesis-inside-square-brackets syntax (aka "banana-in-a-box") creates a two-way binding
  template: '<custom-checkbox [(checked)]="isAdmin" />',
})

export class UserProfile {
  protected isAdmin = signal(false);
}

Dans cet exemple ci-dessus, le CustomCheckbox peut écrire des valeurs dans checked, qui propage ensuite ces valeurs vers isAdmin dans UserProfile. Cette liaison permet de synchroniser les valeurs de checked et de isAdmin. Cependant, il est très important de noter qu'ici, la liaison transmet le signal isAdmin lui-même, et non la valeur du signal.

Pour finir, en nous basant sur le principe du two-way binding, lorsque nous déclarons un Model Input dans un composant ou une directive, Angular crée automatiquement un event correspondant. Voici un exemple :

@Directive({...})
export class CustomCheckbox {
  // This automatically creates an output named "checkedChange".
  // Can be subscribed to using `(checkedChange)="handler()"` in the template.
  checked = model(false);
}

Angular émet cet event de changement chaque fois que nous écrivons une nouvelle valeur dans le Model Input en appelant les méthodes set() ou update().

Différences entre model() et input()

Nous avons commencé cet article en essayant de voir la similarité entre un Signal Input et un Model Input. A présent, nous verrons les éléments qui les différencient :

• model() définit à la fois un input et un output. Le nom de l'output est toujours le nom de l'input suffixé par Change pour prendre en charge les liaisons bidirectionnelles. C'est au composant qui l'implémente de décider s'il veut utiliser seulement l'input, seulement l'output, ou les deux.

• ModelSignal est un WritableSignal, ce qui signifie que sa valeur peut être modifiée de n'importe où à l'aide des méthodes set() et update(). Lorsqu'une nouvelle valeur est attribuée, le ModelSignal émet un output. Il en va différemment de l'InputSignal, qui est en read-only.

• Les Model Inputs ne prennent pas en charge transform, contrairement aux Signal Inputs.

En somme, dans cet article, l'objectif a été de vulgariser le concept de Model Input. Bien qu'ayant une similarité avec le Signal Input, nous avons remarqué qu'il est beaucoup plus proche de la philosophie autour du ngModel à travers le two-way binding mais basé sur Angular Signal. Toutefois, il faut noter que Model Input est toujours Developer Preview.

Pour plus d'informations 👉 Model Inputs

Qu'est-ce qu'un Signal Input en Angular ?

Avant de définir ce qu'est un Signal Input, faisons un peu d'histoire. En Angular, pour passer des propriétés d'un composant parent A à un composant enfant B, nous utilisons habituellement les @Input(). Voici un exemple :

import {Component, input} from '@angular/core';
@Component({...})
export class ComponentB {
  @Input() age: number;
}

<!--- Parent component side (ComponentA) --->
<component-b [age]='10' />

Avec l'arrivée de Signal en Angular, la core team de Angular a introduit une nouvelle méthode pour gérer cette communication, appelée Signal Input, afin d'optimiser les performances du framework.

Le Signal Input joue le même rôle que @Input()c'est-à-dire permettre l'injection de données du composant parent A vers le composant enfant B.

Comment utiliser un Signal Input ?

Angular prend en charge deux variantes de Signal Input à savoir :

• Optional input : Il faut souligner que le Signal Input est optionnel par défaut. Tout comme le @Input(), si au niveau du composant parent A, nous ne faisons pas passer l'input en propriété au composant enfant B, ce n'est pas bloquant. Voici un exemple de composant utilisant le Optional Signal Input :

    import {Component, input} from '@angular/core';
    @Component({...})
    export class MyComp {
      // optional
      firstName = input<string>();         // InputSignal<string|undefined>
      age = input(0);                      // InputSignal<number>
    }
  

  Pour le Signal Input nommé firstName, on note que le type est string | undefined. En effet, si l'on ne spécifie pas une valeur initiale à un Signal Input qui optionnel même après l'avoir typé, Angular utilisera le type undefined de façon implicite. Il faut donc penser à initialiser votreSignal Inputavec une valeur quand il est optionnel.

• Required input : Ici, le Signal Input est rendu obligatoire et il est nécessaire d'indiquer le type de la donnée à recevoir. En voici un exemple :

    import {Component, input} from '@angular/core';
    @Component({...})
    export class MyComp {
      // required
      lastName = input.required<string>(); // InputSignal<string>
    }
  

Tout comme le @Input() classique que nous connaissons jusque-là, le Signal Input aussi peut être utilisé avec des alias. Le but des alias c'est d'éviter des conflits de noms d'attributs. Voici un exemple lié à l'utilisation d'un alias sur un Signal Input :

import {Component, input} from '@angular/core';
@Component({...})
export class MyComp {
  age = input(0, {alias: 'studentAge'});
}

<!--- Parent component side --->
<my-comp [studentAge]='10' />

A présent, nous parlerons d'une spécifité propre au Signal Input que nous n'avons pas avec @Input(). Il s'agit de la transformation de valeur [cette expression fait penser aux Pipes 😃]. En effet, tout comme la philosophie derrière un Pipe, nous sommes capables avec un Signal Inputde faire un traitement sur la valeur d'entrée sans en modifier le sens. La transformation convertira donc la valeur brute envoyée par le parent au type d'entrée attendu. La transformation doit être une fonction pure. En voici une illustration :

class MyComp {
  disabled = input(false, {
    transform: (value: boolean|string) => typeof value === 'string' ? value === '' : value,
  });
}

Dans l'exemple ci-dessus, nous déclarons un Signal Input nommé disabled qui accepte des valeurs de type boolean et string. Ces valeurs (peu importe quelles soientbooleanoustring) sont ensuite traitées enbooleanavec la transformation, ce qui donne desboolean.

De cette façon, nous ne traitons que du boolean à l'intérieur de notre composant enfant lorsque nous appelons this.disabled(), tandis au niveau de notre composant parent, nous pouvons passer un string comme raccourci pour marquer notre composant disabled.

Pour finir, tout ce qui a été abordé dans ce précédent article concernant les Signals est valable pour les Signal Inputs à savoir les méthodes computed() et effect().

Pourquoi et quand faut t-il choisir Signal Input au lieu de @Input() ?

Le Signal Input est une alternative réactive à la méthode @Input(). Voici les nombreux avantages qu'offrent un Signal Input en nous basant sur la documentation :

• Le required input de Signal Input ne nécessite pas de valeur initiale ou d'astuce pour indiquer à TypeScript qu'un input a toujours une valeur.

• Les transformations (transform) sont automatiquement vérifiées pour correspondre aux valeurs acceptées.

• Les Signal Inputs, lorsqu'ils sont utilisées dans des templates, marqueront automatiquement les composants OnPush en dirty. Avec@Input(), il fallait le faire soi-même pour permettre le changement de détection.

• L'utilisation de la méthode effect() au lieu de ngOnChanges() ou setters qui rend plus facile et aisé le contrôle du changement des valeurs.

En somme, nous avons à présent une compréhension plus poussée de l'essentiel à connaître sur les Signal Inputs. Nous aborderons dans de prochains articles, d'autres concepts liés à Angular Signal.

Pour plus d'informations 👉 Signal Inputs

Est-ce que Angular Signals remplacera RxJS ?
Est-ce que Angular Signals et RxJS sont complémentaires ?
Quel sera l'avenir de RxJS dans Angular ?

Cet article vise à mettre la lumière sur ces interrogations ainsi que sur l'utilisation du package RxJS Interop que la core team de Angular a mis à disposition des développeurs.

Est-ce que Angular Signals remplacera RxJS ?

Angular Signals n'a pas pour but de remplacer RxJS. Le concept de Signals a été introduit afin d'optimiser le système de détection des changements dans nos composants Angular lorsque nous mettons à jour une variable ou un objet. Ce système a été conçu autour la bibliothèque Zone.js qui a démontré ces limites que j'ai eues à évoquer précédemment dans cet article Les nouveautés en Angular 16 (Partie 1)
Nous comprenons donc que Zone.js n'a rien avoir techniquement avec RxJS. Ce sont deux bibliothèques bien distinctes qui ont des buts différents.

Est-ce que Angular Signals et RxJS sont complémentaires ?

Maintenant que nous savons que Angular Signals n'est pas là pour remplacer RxJS, nous aborderons leur complémentarité.

Après avoir suivi plusieurs discussions entre les membres de la core team et ceux de la communauté Angular, je peux affirmer que oui 😃

En effet, les Signalspermettent une gestion d'état synchrone tandis que la bibliothèque RxJS le fait de manière asynchrone. La décision de choisir entre l'utilisation de RxJS ou celle de Signals dépendra donc de la complexité de nos opérations asynchrones et de l'environnement de développement existant. Pour des scénarios asynchrones complexes et des architectures basées sur des événements, RxJS offre des outils puissants. En revanche, pour des cas simples d'événements typiquement synchrone ou lorsqu'une meilleure intégration avec les fonctionnalités spécifiques d'Angular est souhaitée, les Signals peuvent être plus appropriés.

Quel sera l'avenir de RxJS dans Angular ?

Après être penché sur les deux premières interrogations qui constituaient des points d'ombre, il est légitime de se demander ce que nous réserve la core team Angular par rapport à l'utilisation de RxJS dans le futur.

L'objectif de la core team de Angular est de rendre optionnel l'installation de bibliothèque RxJS dans un projet Angular c'est-à-dire qu'à la création d'un projet Angular, la bibliothèque RxJS ne sera plus une dépendance installée par défaut. Toutefois, la core team est bien consciente de la puissance des fonctionnalités de RxJS. Pour faciliter la transition, ils ont mis en place le package RxJS Interop.

RxJS Interopd'Angular fournit des utilitaires utiles pour intégrer Angular Signals avec les observables RxJS. Voici quelques utilitaires ou helpers (en anglais) que nous offre cette nouvelle bibliothèque :

• toSignal

La fonction toSignal permet de créer un signal qui écoute en permanence la valeur d'un Observable. Son comportement est similaire à celui du pipe async que nous utilisons dans nos templates HTML, mais il est plus flexible et peut être utilisé n'importe où dans une application. Voyons ensemble ce cas d'utilisation :

import { Component } from '@angular/core';
import { AsyncPipe } from '@angular/common';
import { interval } from 'rxjs';
@Component({
  template: `{{ counter() }}`,
})
export class Ticker {
  counterObservable = interval(1000);
  // Get a `Signal` representing the `counterObservable`'s value.
  counter = toSignal(this.counterObservable, {initialValue: 0});
}

Comme le pipe async, toSignal s'abonne immédiatement à l'Observable, ce qui peut entraîner des effets de bord. La souscription créée par toSignal se désabonne automatiquement de l'Observable donné lorsque le composant ou le service qui appelle toSignal est détruit. Ainsi, nous pouvons transformer un comportement asynchrone en synchrone en utilisant pleinement le potentiel des Signals.

Cependant,toSignalcrée une souscription. Il faut donc éviter de l'appeler plusieurs fois pour le mêmeObservable, et réutiliser le signal qu'il renvoie.

• toObservable

A l'opposé de l'utilitaire toSignal, utilisez toObservable pour créer un Observable qui écoute en permanence la valeur d'un signal. La valeur du signal est surveillée par un effect qui transmet la valeur à l'Observable lorsqu'elle change. Voici un cas d'utilisation :

import { Component, signal } from '@angular/core';
@Component(...)
export class SearchResults {
  query: Signal<string> = inject(QueryService).query;
  query$ = toObservable(this.query);
  results$ = this.query$.pipe(
    switchMap(query => this.http.get('/search?q=' + query ))
  );
}

Lorsque le signal query change, l'observable query$ émet la dernière requête et déclenche une nouvelle demande HTTP. Dans l'exemple, on remarque l'utilisation deswitchMapqui est un opérateurRxJSce qui est normal car comme nous l'avons précédemment annoncé, pour les tâches asynchronous,RxJSdemeure très efficace.

Il est à noter qu'il reste deux autres utilitaires à savoir outputFromObservable et outputToObservable que nous verrons plus tard dans un nouvel article.

En somme, comme nous l'avons remarqué, pour comprendre l'utilité de RxJS Interop, il faut d'abord comprendre ce à quoi est destiné d'une part Angular Signals et d'autre part RxJS. Aujourd'hui, au travers de cet article, nous avons les idées claires de ce qu'il en sera du future de RxJS avec l'arrivée de Angular Signals.

Pour plus d'informations 👉 RxJS Interop

Qu'est-ce qu'un signal en Angular ?

Avant d'entrer dans le vif du sujet, faisons un peu d'histoire. Dans ce précédent article Les nouveautés en Angular 16 (Partie 1), j'ai parlé de Signal et de pourquoi il est innovant. Je vous conseille de le lire pour mieux comprendre la suite.

En nous basant sur la documentation de Angular, voici comment il a été défini :

Angular Signals est un système qui suit de manière granulaire comment et où votre état est utilisé dans une application, permettant au framework d'optimiser les mises à jour de rendu.

Ce qui captive l'attention dans cette définition c'est l'expression suivre de manière granulaire. Cela signifie tout simplement que le système mis en place écoute en permance point à point les changements des états des variables utilisées dans votre application qui sont basées sur le concept de Signals. Ainsi, le temps de réponse lié au rendu de ces variables ou objets dans le DOM est considérablement réduit ce qui rend notre application plus performante.

En allant plus loin dans la définition, nous apprenons que les Signals peuvent contenir n'importe quelle valeur c'est-à-dire des primitives ou des données complexes. Quand on parle de primitives, il s'agit des types de base à savoir string, number, etc...

Pour finir, il y a un élément crucial à retenir : les Signals peuvent être en écriture ou en lecture seule.

Comment créer un signal et mettre à jour sa valeur ?

Dans cette section, nous verrons comment utiliser un signal en mode écriture c'est-à-dire créer un signal et modifier sa valeur :

• Création d'un signal

Pour créer un signal, voici comment procéder :

const count = signal(0);
console.log('The count is: ' + count());

Comme nous le remarquons sur le code ci-dessus, la création d'un signal se fait au travers de la méthode signal() avec une valeur d'initialisation. Ici, cette valeur c'est 0.
En outre, pour lire la valeur du signal créé qui est count dans l'exemple ci-dessus, nous avons utilisé une syntaxe particulière à savoir count(). Il s'agit tout simplement d'une syntaxe simplifiée lorsque l'objet manipulée possède une méthode get() qui nous retourne la valeur de la variable ou de l'objet. On parle de getter function (en anglais).

• Modification d'un signal

Tout comme la création d'un signal, la modification de sa valeur est aussi simple. Cependant, nous avons deux façons de la faire :

count.set(count() + 1);

// Ou

count.update(value => value + 1);

Dans le premier cas, nous avons utilisé la méthode set() ce qui n'est pas surprenant vu que nous avons une méthode get().

Vous l'aurez compris certainement !
set() pour modifier la valeur
get() pour récupérer la valeur
🤓

Dans le second cas, nous sommes passé par la méthode update(). L'avantage de cette méthode réside dans le fait que nous avons directement l'ancienne valeur de notre signal sur laquelle nous pourrons procéder à des traitements pour la modifier.

A présent, il est crucial de comprendre que lorsque nous décidons de créer un signal qui peut être modifié c'est-à-dire accessible en écriture, Angular le définit comme un WritableSignal.

Bien-sûr vu que vous êtes super doués…on peut déjà se douter qu'il y a des signals qui ne sont pas writable 😂

Pour finir, voici ce que donnerait la création de notre signal avec la déclaration explicite du type :

const count: WritableSignal<number> = signal(0);

Comment créer un signal en lecture seule (read only) ?

Dans le jargon technique de Angular, les signals en lecture seule sont appelés Computed signal.

Pour créer un signal en lecture seule, voici comment procéder :

const count: WritableSignal<number> = signal(0);
const doubleCount: Signal<number> = computed(() => count() * 2);

Comme nous pouvons le lire dans le code ci-dessus, le type de notre signal doubleCount est Signal qui est l'opposé de WritableSignal. Nous nous sommes basés sur l'exemple précédent afin de faire remarquer les différences.

Le signal doubleCount est en lecture seule mais il dépend du signal count qui est en écriture. Si le signal count se met à jour, automatiquement le signal doubleCount le sera.

Pour les plus curieux qui cherchent à comprendre comment s'effectue la lecture seule, voici ce que la documentation de Angular nous enseigne :

Les signals calculés sont à la fois évalués paresseusement et mémoïsés.

La fonction de dérivation de doubleCount ne s'exécute pas pour calculer sa valeur avant la première lecture de doubleCount. La valeur calculée est alors mise en cache, et si vous lisez doubleCount à nouveau, il retournera la valeur mise en cache sans recalculer.

Si vous changez ensuite de compte, Angular sait que la valeur mise en cache de doubleCount n'est plus valide, et la prochaine fois que vous lirez doubleCount, sa nouvelle valeur sera calculée.

Par conséquent, vous pouvez effectuer en toute sécurité des dérivations coûteuses en calcul dans les signaux calculés, comme le filtrage des tableaux.

Dans cette explication, ce qui retient l'attention c'est l'expression mémoïsation. La mémoïsation est une expression en jargon informatique qui signifie tout simplement la mise en cache de la valeur d'une fonction.

Pour finir, on retient de cette section que nous avons deux types de Signals à savoir WritableSignal et Signal.
WritableSignal peut être modifié tandis que Signal est en lecture seule.

Dans la prochaine section, nous parlerons d'une fonctionnalité importante des Signals : les effects.

Les effects

Supposons un instant que nous aimerions faire des traitements lorsque notre signal change de valeur. Jusqu'à présent, nous n'avons aucun moyen de le faire. Comme vous l'auriez compris, les effects nous servirons à les faire.

Un effect est donc une méthode qui se déclenche chaque fois qu'une ou plusieurs valeurs de signals changent. Pour metter en place un effect, voici ce qu'il faut faire :

effect(() => {
  console.log(`The current count is: ${count()}`);
});

Dans le code ci-dessus, nous avons notre effect avec une fonction de callback. La fonction de callback nous permet d'effectuer nos traitements suivant la modification de notre signal.

Les effects sont toujours exécutés au moins une fois. Lorsqu'un effect s'exécute, il suit toutes les valeurs de signals lues. Chaque fois que l'une de ces valeurs change, l'effect s'exécute à nouveau. Comme pour les signals calculés, les effects suivent leurs dépendances de manière dynamique et ne suivent que les signals qui ont été lus lors de l'exécution la plus récente.

Les effects s'exécutent toujours de manière asynchrone, pendant le processus de détection des changements.

En nous rapportant toujours à la documentation de Angular, voici quelques cas d'utilisation des effects :

• Enregistrement des données affichées et de leurs modifications, à des fins d'analyse ou comme outil de débogage.

• Garder les données synchronisées avec window.localStorage.

• Ajouter un comportement DOM personnalisé qui ne peut pas être exprimé avec la syntaxe des modèles.

• Rendre le comportement personnalisé à un , à une bibliothèque graphique ou à une autre bibliothèque d'interface utilisateur tierce.

En somme, nous avons vu ensemble l'essentiel de Angular Signals ainsi que la philosophie derrière cette approche. Nous avons compris à présent la pertinence de Signals en Angular et comment l'utiliser de façon très subtile.

Nous aborderons dans de prochains articles, tout l'écosystème autour de ce concept qui a révolutionné le fonctionnement du framework Angular depuis la version 16.

Pour plus d'informations 👉 Angular Signals

Le but de cet article est de mettre la lumière sur comment créer facilement un composant input réutilisable que nous pourrions utiliser dans nos formulaires réactifs.

Etape 1 : Création du composant app-input

Commençons par générer un nouveau composant avec la commande Angular CLI :

  ng generate component input

Nous modifierons le template de notre composant pour avoir ceci de façon très basique :

  <input type="text" [formControl]="control"/>

Etape 2: Implémentation de ControlValueAccessor

Pour que notre composant puisse être utilisé dans un formulaire réactif ou un formulaire basé sur des modèles, nous devons implémenter l'interface ControlValueAccessor.

Nous avons besoin de l'interface ControlValueAccessor parce que lorsqu'on crée le composant et qu'on désire l'utiliser dans un composant parent, nous ne devons pas oublier qu'il sera encapsulé dans son sélecteur app-input (dans notre cas ici). Ainsi, tous les attributs auxquels l'on avait accès directement sur un input ne seront plus disponibles. C'est davantage plus difficile si l'on veut avoir le contrôle sur notre composant via un formulaire réactif ou un formulaire basé sur des modèles.

Cette interface fournit une série de méthodes que nous pouvons utiliser pour synchroniser la valeur de notre composant avec un FormControl.

Nous pouvons le faire en ajoutant les méthodes suivantes à notre composant :

onChange: any = () => {};

onTouched = () => {};

writeValue(value: any): void {
    // mettre à jour la valeur de votre composant
}

registerOnChange(fn: any): void {
 // enregistrer une fonction qui sera appelée lorsque la valeur du composant change
 this.onChange = fn;
}

registerOnTouched(fn: any): void {
 // enregistrer une fonction qui sera appelée lorsque le composant est touché
 this.onTouched = fn;
}

Lorsqu'on implémente l'interface ControlValueAccessor, ces trois méthodes sont automatiquement redéfinies dans notre composant. Ces méthodes permettront à notre composant d'écouter les changements et de les enregistrer suivant le besoin.

Il faut aussi penser à rendre accessible l'objet AbstractControl afin de pouvoir effectuer des manipulations dans le template HTML de notre composant pour soit afficher des messages d'erreur ou gérer des scénarios. Voici ce qu'il faut faire :

...

public control: AbstractControl;

...

constructor(private injector: Injector) {}

ngAfterViewInit(): void {
    const ngControl = this.injector.get(NgControl, null);
    if (ngControl) {
      setTimeout(() => {
        this.control = Object.assign(new FormControl(), ngControl.control) as FormControl;
      });
    }
  }

Cette initialisation dans la méthode ngAfterViewInit nous permet d'accéder facilement à l'objet AbstractControl de notre composant input et de prévenir un problème lié à l'appel de notre composant dans un composant parent. En effet, le setTimeout est utilisé pour s'assurer que le DOM a été bien initialisé par le parent pour permettre l'utilisation de notre composant enfant.

Nous devons également fournir un provider pour notre composant qui indique à Angular d'utiliser notre composant comme un ControlValueAccessor :

  providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      useExisting: forwardRef(() => InputComponent),
      multi: true
    }
  ]

Etape 3 : Utilisation du composant dans un formulaire

Maintenant que notre composant est un ControlValueAccessor, nous pouvons l'utiliser dans un formulaire réactif. Voici un exemple :

  <form [formGroup]="form">
    <app-input formControlName="firstname"></app-input>
  </form>

Nous pouvons obtenir la valeur du composant en utilisant form.get('firstname').value et nous pouvons définir la valeur du composant en utilisant form.get('firstname').setValue(value).

Est-ce que ça fonctionne aussi avec [(ngModel)] ?

La question de savoir si ngModel est pris en compte par le ControlValueAccessor est très récurrente !

La réponse est OUI. Nous pouvons utiliser ngModel sur un composant piloté par ControlValueAccessor et ça fonctionne parfaitement :

 <app-input [(ngModel)]="value"></app-input>

En somme, lorsque nous décidons de créer des composants réutilisables de type input, pensons toujours à implémenter l'interface ControlValueAccessor pour avoir cette flexibilité à pouvoir l'utiliser dans un formulaire réactif (Reactive Form) ou un formulaire basé sur des modèles (Template-Driven Form).

Pour plus d'informations :

👉 ControlValueAccessor

👉 Reactive Forms

👉 Template-Driven Forms

• écrire un test qui échoue avant d'écrire le code ;

• interdire d'écrire un test plus compliqué que nécessaire ;

• éviter d'écrire plus de code que nécessaire, mais seulement ce qu'il faut pour réussir le test qui a échoué.

Ces trois (03) règles fonctionnent ensemble dans le cadre d'un processus appelé le cycle rouge-vert-refactorisation (red-green-refactor en anglais).

Le processus TDD est itératif et implique l'écriture d'un test qui échoue, l'écriture du code pour réussir le test, puis le refactorisation du code pour améliorer sa conception et sa maintenabilité. Le processus est répété jusqu'à ce que le code soit complet. En écrivant d'abord les tests, la méthode TDD garantit que le code est correct et répond aux exigences définies dans les tests. Elle encourage également les développeurs à écrire un code propre, facile à maintenir, à modifier et à faire évoluer.

Dans cet article, nous allons nous concentrer sur l'introduction au TDD en utilisant Angular, un framework JavaScript populaire pour le développement d'applications web. Nous allons créer une application de calculatrice simple pour illustrer les concepts du TDD.

Étape 1: Création du projet Angular

Avant de commencer à développer notre application de calculatrice, nous devons naturellement créer notre projet en utilisant la commande suivante :

ng new calculator-app

Étape 2: Création du composant de calculatrice

Maintenant que notre projet est créé, nous pouvons commencer à développer notre application de calculatrice. Créez un nouveau composant de calculatrice en utilisant la commande suivante:

ng generate component calculator

Cette commande créera un nouveau dossier calculator contenant les fichiers nécessaires pour notre composant de calculatrice. Nous travaillerons dans un premier temps dans le fichier calculator.component.spec.ts .

Étape 3: Exploration du fichier calculator.component.spec.ts

Lorsque vous ouvrez le fichier, voici le code que vous avez par défaut :

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { CalculatorComponent } from './calculator.component';

describe('CalculatorComponent', () => {
  let calculator: CalculatorComponent; // component a été remplacé par calculator
  let fixture: ComponentFixture<CalculatorComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [ CalculatorComponent ]
    })
    .compileComponents();

    fixture = TestBed.createComponent(CalculatorComponent);
    calculator = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(calculator).toBeTruthy();
  });
});

Dans le code généré ci-dessous, nous avons une suite de tests utilisant la fonction describe, qui fournit un nom descriptif pour le composant testé. Dans la suite de tests, nous avons un bloc beforeEach pour configurer l'environnement de test. La méthode TestBed.configureTestingModule est utilisée pour configurer le module de test et fournir les dépendances nécessaires. La variable calculator est ensuite assignée à une instance du CalculatorComponent à l'aide de la méthode TestBed.inject.

Etape 4: Ecriture de notre premier test

Notre composant CalculatorComponent nous permettra d'effectuer des opérations arithmétiques de base. Pour écrire un test unitaire en utilisant le TDD, nous allons commencer par créer un scénario de test qui vérifie le comportement attendu du composant. Nous allons maintenant écrire le scénario de test proprement dit en utilisant la fonction it. Dans ce cas, nous allons tester la méthode add du CalculatorComponent en lui passant deux nombres et en nous attendant à ce que le résultat soit 5. La fonction expect est utilisée pour définir le comportement attendu et vérifier le résultat réel. Ce code doit être ajouté à la suite de tests, c'est-à-dire à l'intérieur de la fonction describe.

  it('should add two numbers correctly', () => { 
    const result = calculator.add(2, 3); 
    expect(result).toBe(5); 
 });

Etape 4: Exécution du test

Avant même d'exécuter le test, vous obtenez une erreur dans votre éditeur de code vous indiquant que la fonction add n'existe pas.

C'est normal, puisqu'elle n'a pas encore été créée.

Ensuite, en retournant sur notre serveur Karma, nous constatons que notre test case n'est pas affiché dans CalculatorComponent` et dans le terminal, nous avons une erreur liée à l'inexistence de la fonction et un message indiquant qu'aucun test n'a réussi.

Pas de panique, c'est le rouge du TDD ! Bravo 😂

Etape 5: Ecriture du code minimum pour que le test passe

Dans notre classe CalculatorComponent, en suivant l'approche TDD, nous allons écrire le minimum de code nécessaire pour que notre test précédemment écrit passe.

add(a: number, b: number): number { 
    return a + b; 
}

Le résultat sur votre serveur Karma :

Et dans votre terminal :

Nous en sommes à l'étape green du TDD, c'est-à-dire que nous écrivons la quantité minimale de code nécessaire pour que notre test soit réussi.

C'est très bien !

Etape 6: Refactoriser le code

Une fois les tests réussis, vous pouvez refactoriser le code pour en améliorer la conception, la lisibilité et la maintenabilité. La refactorisation est une étape essentielle du processus TDD, qui permet d'éliminer les doublons, d'améliorer la structure du code et la qualité globale. Il est essentiel de s'assurer que les tests continuent à fonctionner après la refactorisation. La révision et la mise à jour régulière des tests au fur et à mesure de l'évolution de la base de code contribueront à maintenir l'intégrité et la fiabilité des tests unitaires.

Maintenant, faites le même exercice pour rajouter les autres types d'opérations qu'on retrouve sur une calculatrice. Vous remarquerez que vous passez plus de temps dans votre éditeur de texte ou IDE que sur le navigateur et dans votre terminal. À aucun moment, vous n'avez eu besoin d'ouvrir votre navigateur sauf pour visualiser quoique ce soit à part le résultat du serveur Karma.

Pour plus d'informations :

👉 Jasmine
👉 Karma

Comment notre application réagirait avec une connexion internet dont le débit est faible ?

La plupart d'entre nous ne se pose la question qu'à la fin du projet 😂

Dans cet article, nous verrons comment Angular nous permet de contrôler et de gérer le chargement de nos bundles (le code JS qui s'occupe de l'affichage de notre page web) en se basant sur le débit de la connexion internet.

Nous prendrons l'exemple d'une petite application Angular ayant trois composants à savoir HomeComponent, AboutComponent et ContactComponent qui seront chargés de façon paresseuse (lazy).

1- Création d'un nouveau projet Angular à l'aide de la CLI Angular :

ng new testing-internet-connection --routing

2- Création de trois composants Angular implémentant chacun le routing :

ng g m home --route home --module=app.module
ng g m about --route about --module=app.module
ng g m contact --route contact --module=app.module

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

@Component({
  selector: 'app-home',
  template: `<h1>Home</h1>`
})
export class HomeComponent { }

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

@Component({
  selector: 'app-about',
  template: `<h1>About</h1>`
})
export class AboutComponent { }

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

@Component({
  selector: 'app-contact',
  template: `<h1>Contact</h1>`
})
export class ContactComponent { }

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';
import { HomeComponent } from './home.component';

@NgModule({
  declarations: [HomeComponent],
  imports: [
    CommonModule,
    RouterModule.forChild([{ path: '', component: HomeComponent }])
  ]
})
export class HomeModule { }

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';
import { AboutComponent } from './about.component';

@NgModule({
  declarations: [AboutComponent],
  imports: [
    CommonModule,
    RouterModule.forChild([{ path: '', component: AboutComponent }])
  ]
})
export class AboutModule { }

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';
import { ContactComponent } from './contact.component';

@NgModule({
  declarations: [ContactComponent],
  imports: [
    CommonModule,
    RouterModule.forChild([{ path: '', component: ContactComponent }])
  ]
})
export class ContactModule { }

3- Création d'un service appelé InternetConnectionService qui nous permet de détecter la qualité de la connexion internet :

ng g s internet-connection

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

declare var navigator: any;

@Injectable({
  providedIn: 'root'
})
export class InternetConnectionService {

  constructor() { }

  getSpeed(): string {
    const connection = navigator.connection;
    const type = connection.effectiveType;
    const speed = connection.downlink;

    if (type === 'slow-2g' || speed < 0.5) {
      return '2G';
    } else if (type === '2g' || speed < 1) {
      return '3G';
    } else {
      return '5G';
    }
  }
}

4- Création d'une stratégie de préchargement personnalisée appelée InternetConnectionPreloadingStrategy :

import { PreloadingStrategy, Route } from '@angular/router';
import { Observable, of } from 'rxjs';
import { InternetConnectionService } from './internet-connection.service';

@Injectable({ providedIn: 'root' })
export class InternetConnectionPreloadingStrategy implements PreloadingStrategy {

  constructor(private connectionService: InternetConnectionService) { }

  preload(route: Route, load: () => Observable<any>): Observable<any> {
    const quality = this.connectionService.getSpeed();

    if (quality === '5G') {
      return load();
    } else {
      return of(null);
    }
  }
}

• Notre stratégie InternetConnectionPreloadingStrategy implémente l'interface PreloadingStrategy parce que nous devons redéfinir la méthode preload() en y rajoutant la logique basée sur la qualité de la connexion internet.

5- Modification de app-routing.module.ts :

Dans notre fichier, app-routing.module.ts, voici ce que nous avons jusque-là :

import { NgModule } from '@angular/core';
import { Routes, RouterModule } from '@angular/router';

const routes: Routes = [
  { path: '', loadChildren: () => import('./home/home.module').then(m => m.HomeModule) },
  { path: 'about', loadChildren: () => import('./about/about.module').then(m => m.AboutModule) },
  { path: 'contact', loadChildren: () => import('./contact/contact.module').then(m => m.ContactModule) }
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

Comme nous pouvons le remarquer, c'est du classique. À présent, nous procéderons à quelques modifications afin d'ajouter notre stratégie de pré-chargement qui dépend de la qualité de notre connexion internet. Voici le résultat :

import { NgModule } from '@angular/core';
import { Routes, RouterModule, PreloadAllModules, PreloadingStrategy, Route } from '@angular/router';
import { InternetConnectionPreloadingStrategy } from './internet-connection-preloading-strategy';

const routes: Routes = [
  { path: '', loadChildren: () => import('./home/home.module').then(m => m.HomeModule) },
  { path: 'about', loadChildren: () => import('./about/about.module').then(m => m.AboutModule) },
  { path: 'contact', loadChildren: () => import('./contact/contact.module').then(m => m.ContactModule) }
];

@NgModule({
  imports: [RouterModule.forRoot(routes, {
    preloadingStrategy: InternetConnectionPreloadingStrategy
  })],
  exports: [RouterModule]
})
export class AppRoutingModule { }

• L'attribut preloadingStrategy nous permet d'indiquer notre stratégie de pré-chargement.

6- Modification du composant AppComponent :

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

@Component({
  selector: 'app-root',
  template: `
    <nav>
      <a routerLink="/" routerLinkActive="active">Home</a>
      <a routerLink="/about" routerLinkActive="active">About</a>
      <a routerLink="/contact" routerLinkActive="active">Contact</a>
    </nav>
    <router-outlet></router-outlet>
  `
})
export class AppComponent { }

7- Débogage avec un navigateur en simulant différents débits de connexion Internet :

En inspectant notre navigateur après avoir lancé la commande ng serve -o, nous pouvons nous rendre dans l'option Réseau et simuler le débit de la connexion internet que nous désirons à savoir (2G, 3G, 4G ou 5G). En fonction de ce débit, nous pourrons observer le comportement lié aux chargements des modules qui s'occupent de l'affichage de nos trois (03) pages web créés précédemment.

En somme, nous avons vu comment définir une stratégie de pré-chargement de nos bundles suivant le débit de la connexion internet de l'utilisateur afin de lui garantir une meilleure expérience utilisateur. Si vos utilisateurs sont susceptibles d'être mobiles et de bénéficier d'une faible bande passante ou d'un faible niveau de WiFi ou de données mobiles, cette stratégie de pré-chargement pourrait s'avérer bénéfique. Si vous n'êtes pas sûr de vous, vous pouvez consulter vos utilisateurs professionnels (les parties prenantes de votre application) pour vous en rendre compte. Vous pouvez également combiner cette stratégie avec l'une des autres stratégies personnalisées. Avant de choisir cette option, ou toute autre stratégie de pré-chargement, il est recommandé d'effectuer des tests à différentes vitesses de réseau dans le cadre de différents flux de travail d'utilisateurs valides et courants. Ces données pourrons vous aider à la prise de décision afin de garantir une meilleure expérience utilisateur à vos utilisateurs.

Pour plus d'informations :

👉 Angular Preloading Strategy

👉 Preload Angular Bundles by John Papa

En effet, Jasmine est un framework qui nous permet d'aller vite dans l'écriture de nos tests unitaires et Karma est un serveur qui nous permet de lancer nos tests avec un rendu de tout ce qui se passe sur notre navigateur.

Considérons un composant réutilisable HelloComponent qui permet d'afficher le nom de l'utilisateur (username) dès qu'on clique sur un bouton (Hello).

<div>
    <p> {{ username }} </p>
   <button (click)='sayHello(username)'> Hello </button>
</div>

export class HelloComponent {
    @Input() username = '';
    @Output() hello = new EventEmitter<string>()

    public sayHello(username: string): void {
        this.hello.emit(username);
    }
}

Comme nous pouvons le pouvoir, nous avons notre composant HelloComponent qui comprend :

• username qui est notre propriété Input()

• hello qui est notre évènement Output()

Notre composant réutilisable pourra être appelé par un composant parent comme ceci par exemple :

<app-hello [username]="'john'" (hello)="onSayHello($event)">
</app-hello>

En créant un composant Angular, nous avons généralement un fichier qui a pour extension `.spec.ts` . C'est le fichier dédié à l'écriture des tests unitaires liés à notre composant. En ouvrant le fichier hello.component.spec.ts qui fait référence à notre composant HelloComponent, nous avons ce code de base :

import { ComponentFixture, TestBed } from '@angular/core/testing';

import { NotificationToastComponent } from './hello.component';

describe('HelloComponent', () => {
  let component: HelloComponent;
  let fixture: ComponentFixture<HelloComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [ HelloComponent ]
    })
    .compileComponents();

    fixture = TestBed.createComponent(HelloComponent);
    component = fixture.componentInstance;
    component.username = 'john';
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(component).toBeTruthy();
  });
});

• Le code généré nous a créé une instance du composant HelloComponent. Ensuite, il a fait appel à la méthode detectChanges() pour mettre à jour la vue si entre temps une propriété du composant a été modifié.

• Nous avons rajouté component.username = 'john'; afin qu'il initialise la valeur de username avec 'john' lors de la création de l'instance.

Nous pouvons à présent écrire les tests unitaires qu'il faut par rapport à notre logique métier. Nous écrirons deux tests unitaires :

1) Le premier test vise à vérifier que notre variable username est bien affichée sur notre interface :

it('should display username', () => {
  const messageElement = fixture.nativeElement.querySelector('p');
  expect(messageElement.textContent).toContain('john');
});

• Dans notre premier test ci-dessus, nous avons sélectionné l'élément HTML qui affiche la propriété username et vérifié qu'il contient la valeur "john". La valeur de username a été initialisée dans la méthode beforeEach() .

2) Le second test vise à vérifier que l'évènement hello() est émise lorsqu'on fait appel à la méthode sayHello() :

   it('should emit hello event', () => {
    spyOn(component.hello, 'emit');
    component.sayHello('john');
    expect(component.hello.emit).toHaveBeenCalledWith('john');
  });

• Dans notre second test ci-dessus, nous avons utilisé la méthode spyOn() pour espionner l'évènement hello(). En effet, spyOn() est une fonction qui enregistre des informations sur les appels de la méthode à espionner, comme le nombre de fois où elle a été appelée, avec quels arguments et ce qu'elle a renvoyé. Enfin, nous avons vérifié que l'événement hello() a été émis avec la valeur 'john' lorsqu'on appelle la fonction sayHello().

Nous pouvons lancer la commande ng test pour lancer le serveur Karma et voir le rendu de nos tests unitaires sur un navigateur.

Pour finir, voici le code complet lié aux tests unitaires sur notre composant HelloComponent :

import { ComponentFixture, TestBed } from '@angular/core/testing';

import { NotificationToastComponent } from './hello.component';

describe('HelloComponent', () => {
  let component: HelloComponent;
  let fixture: ComponentFixture<HelloComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [ HelloComponent ]
    })
    .compileComponents();

    fixture = TestBed.createComponent(HelloComponent);
    component = fixture.componentInstance;
    component.username = 'john';
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(component).toBeTruthy();
  });

  it('should display username', () => {
      const messageElement = fixture.nativeElement.querySelector('p');
      expect(messageElement.textContent).toContain('john');
  });

  it('should emit hello event', () => {
    spyOn(component.hello, 'emit');
    component.sayHello('john');
    expect(component.hello.emit).toHaveBeenCalledWith('john');
  });
});

En somme, nous avons exploré comment écrire des tests unitaires pour un composant Angular qui utilise les décorateurs @Input() et @Output(). Les tests unitaires sont une partie importante du processus de développement logiciel et nous espérons que nous les aborderons davantage avec plus d'aisance et moins de peur.

Pour plus d'informations :

👉 Angular Testing

👉 Jasmine Documentation

esbuild dev-server

Il y a plus d'un an, la core team de Angular a annoncé un support expérimental pour esbuild dans la CLI de Angular afin de rendre les builds plus rapides. Aujourd'hui, avec Angular 16, le système de build basé sur esbuild entre en developer preview. Les premiers tests ont montré une amélioration de 72% dans les builds de production à froid.

Au lancement de la commande ng serve, nous pouvons maintenant utiliser Vite (créé par Evan You, le créateur de Vue.js) pour le serveur de développement, et esbuild pour nos builds de développement et de production.

La core team de Angular a mis l'accent sur le fait que la CLI de Angular s'appuie exclusivement sur Vite en tant que serveur de développement. Pour supporter la correspondance des sélecteurs, le compilateur Angular doit maintenir un graphe de dépendance entre nos composants, ce qui nécessite un modèle de compilation différent de celui de Vite.

Pour essayer Vite + esbuild il faut mettre à jour notre fichier angular.json en faisant ceci :

...
"architect": {
  "build": {                     /* Add the esbuild suffix  */
    "builder": "@angular-devkit/build-angular:browser-esbuild",
...

Angular Material Component

La core team de Angular a annoncé qu'au cours des deux derniers trimestres, qu'elle a travaillé en étroite collaboration avec l'équipe Material Design de Google pour fournir l'implémentation de la référence de Material 3 pour le Web avec Angular Material. Les composants Web MDC qui ont été livrés en 2022 ont révélé les bases de cet effort.

La prochaine étape consistera à lancer plus tard dans l'année une API de thématisation expressive basée sur des jetons qui permettra une personnalisation plus poussée des composants matériels d'Angular.

API to provide CSP nonce for inline stylesheets

Les éléments de style en ligne que Angular inclut dans le DOM pour les styles de composants violent la politique de sécurité du contenu par défaut style-src (CSP). Pour corriger cela, ils devraient soit contenir un attribut nonce, soit le serveur devrait inclure un hachage du contenu du style dans l'en-tête CSP. Même si Google n'a pas trouvé de vecteur d'attaque significatif pour cette vulnérabilité, de nombreuses entreprises appliquent une CSP stricte, ce qui a conduit à la popularité d'une demande de fonctionnalité sur le référentiel Angular.

Dans Angular 16, la core team a implémenté une nouvelle fonctionnalité couvrant le framework, Universal, CDK, Material, et le CLI qui nous permet de spécifier un attribut nonce pour les styles des composants inline. Il y a deux façons de spécifier le nonce . Soit en utilisant l'attribut ngCspNonce ou à travers le jeton d'injection CSP_NONCE.

L'attribut ngCspNonce est utile si vous avez accès à un modèle côté serveur qui peut ajouter le nonce à la fois à l'en-tête et dans le fichier index.html lors de la construction de la réponse.

<html>
<body>
  <app ngCspNonce="{% nonce %}"></app>  
</body>
</html>

L'autre façon de spécifier nonce est d'utiliser le jeton d'injection CSP_NONCE. Nous pouvons utiliser cette approche si nous avons accès à nonce au moment de l'exécution et que nous voulons mettre en cache le fichier index.html :

import {bootstrapApplication, CSP_NONCE} from '@angular/core';
import {AppComponent} from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [{
    provide: CSP_NONCE,
    useValue: globalThis.myRandomNonceValue
  }]
});

Configure zone in bootstrapApplication

Dans l'article précédent mentionné plus haut, nous avons vu que Signals a remplacé Zone.js. Toutefois, Zone.js n'a pas disparu de Angular.

D'après la core team de Angular, après la publication initiale des API autonomes (standalone), des développeurs ont exprimé leur souhait de pouvoir configurer Zone.js avec la nouvelle API bootstrapApplication.

Elle a donc ajouté une option pour le faire via provideZoneChangeDetection :

bootstrapApplication(App, {
  providers: [provideZoneChangeDetection({ eventCoalescing: true })]
});

Balises de fermeture automatique

Il s'agit d'une fonctionnalité très demandée qui a été récemment mise en œuvre qui nous permet d'utiliser des balises de fermeture automatique pour les composants dans les templates Angular. Il s'agit d'une petite amélioration de l'expérience du développeur qui pourrait nous faire économiser de la saisie.

Nous pouvons désormais remplacer :

<my-component [prop]="props"></my-component>

Par ceci :

<my-component [prop]="props"/>

En somme, nous avons vu en deux parties l'essentiel sur les nouveautés liées à Angular 16. J'ai hâte de découvrir les merveilles que nous ferons avec cette nouvelle version.

Pour plus d'informations 👉 Angular v16 is here

Signals

Si vous êtes à l'écoute de la communauté Angular, vous avez déjà certainement entendu parler du mot "Signals" qui a sucité beaucoup d'engouements. En effet, jusqu'à la version 15 de Angular c'est la bibliothèque Zone.js qui permet à Angular de détecter les changements dans l'application de manière plus efficace et de mettre à jour l'interface utilisateur de manière plus rapide, ce qui peut améliorer la réactivité de l'application. Cependant, Zone.js pose essentiellement quatre (04) problèmes qui sont :

• Zone.js a un surcoût d'environ 100 Ko. Bien que négligeable pour les applications de grande taille, cette surcharge est rédhibitoire pour le déploiement de composants web légers.

• Avec Zone.js, les objets du navigateur sont modifiés et les erreurs sont difficiles à diagnostiquer.

• Zone.js n'arrive pas à interprèter async et await puisqu'il s'agit de mots-clés. Par conséquent, lors de la compilation, Angular convertit toujours ces déclarations en promesses, même si tous les navigateurs pris en charge supportent déjà async et await en mode natif.

• Lorsque des modifications sont apportées, des composants entiers, y compris leurs prédécesseurs, sont toujours vérifiés dans l'arborescence des composants. Il n'est actuellement pas possible d'identifier directement les composants modifiés ou de mettre à jour les parties modifiées d'un composant.

Afin de résoudre ces problèmes, ils ont pensé à la création de Signals. La bibliothèque Signals nous permet de définir des valeurs réactives et d'exprimer des dépendances entre elles. Elle est souple et simple à implémenter. Voyons ensemble un exemple d'implémentation :

@Component({
  selector: 'my-app',
  standalone: true,
  template: `
    {{ fullName() }} <button (click)="setName('John')">Click</button>
  `,
})
export class App {
  firstName = signal('Jane');
  lastName = signal('Doe');
  fullName = computed(() => `${this.firstName()} ${this.lastName()}`);

  constructor() {
    effect(() => console.log('Name changed:', this.fullName()));
  }

  setName(newName: string) {
    this.firstName.set(newName);
  }
}

Rendu côté serveur (SSR) et hydratation améliorés

La core team de Angular a effectué une enquête annuelle afin d'avoir une idée des choses à améliorer dans les prochaines versions. Le résultat a démontré que les développeurs se plaignaient beaucoup du rendu côté serveur. Il y a donc eu naturellement des améliorations à ce niveau. En voici une preuve :

Création des schémas d'applications autonomes

Précédemment, dans cet article, nous avons vu ensemble ce que c'est qu'un composant autonome (standalone). Avec la version 16 de Angular, il est possible via la CLI de créer une application Angular en précisant par défaut que nous voulons créer uniquement des composants autonomes. Voici ce qu'il faut faire :

ng new --standalone

Possibilité d'ajouter la règle "required" sur des Input

Lorsque nous créons un composant réutilisable en Angular, nous utilisons le décorateur @Input() pour préciser les props de notre composant. Jusqu'à la version 15 de Angular, il n'est pas possible de rendre obligatoire nos propriétés lorsque notre composant réutilisable est appelé dans un composant parent. Pour améliorer donc cette expérience développeur, la communauté a suggéré ceci :

@Component(...)
export class App {
  @Input({ required: true }) title: string = '';
}

Utilisation de @Input() dans un Resolver

Cette nouveauté facilite l'utilisation des Resolvers en Angular. Cela consiste tout simplement en ceci :

const routes = [
  {
    path: 'about',
    loadComponent: import('./about'),
    resolve: { contact: () => getContact() }
  }
];

@Component(...)
export class About {
  // The value of "contact" is passed to the contact input
  @Input() contact?: string;
}

Nous remarquons que notre variable contact qui est un @Input() est directement liée à l'objet ayant pour clé le même nom que notre variable présent dans notre Resolver.

DestroyRef & takeUntilDestroyed

• DestroyRef
  La classe DestroyRef a été créée pour faciliter l'utilisation de la méthode ngOnDestroy() qui fait partie du cycle de vie d'un composant Angular. L'idée ici est de pouvoir l'utiliser dans les directives, services, pipes, etc...
  Voici un exemple :

import { Injectable, DestroyRef } from '@angular/core';

@Injectable(...)
export class AppService {
  destroyRef = inject(DestroyRef);

  destroy() {
    this.destroyRef.onDestroy(() => /* cleanup */ );
  }
}

• takeUntilDestroyed
  Avant la création de la méthode takeUntilDestroyed(), voici comment procédons-nous :

destroyed$ = new ReplaySubject<void>(1);

data$ = http.get('...').pipe(takeUntil(this.destroyed$));

ngOnDestroy() {
  this.destroyed$.next();
}

Aujourd'hui avec la version 16 de Angular, nous avons ceci :

data$ = http.get('…').pipe(takeUntilDestroyed());

NGCC, entryComponents et Node.js v14 ne sont pas supportés par Angular 16

La compilation NGCC n'est pas supportée par Angular 16. Il faudra faire attention lors de la montée en version. Il en est de même pour entryComponent qui était obsolète depuis Angular 9. Enfin, il est à souligner que Angular 16 ne supporte pas la version 14 de Node.js.

TypeScript 5.0

La version 16 de Angular supporte le TypeScript 5.0 qui inclut l'utilisation des décorateurs ECMAScript.

En somme, nous avons remarqué à travers cette première partie sur les nouveautés liées à Angular 16, qu'il y a eu beaucoup d'améliorations et que l'expérience développeur est toujours au coeur de ce dernier.

Pour plus d'informations :

👉 Angular v16 is here

👉 Angular Signals by AngularArchitects

Cependant, cette tâche n'est pas si aisée parce qu'il faut s'assurer qu'il n'y a pas de régression après notre montée en version. Nous verrons ensemble comment le faire un toute sérénité.

1. Consulter le site Angular Update Guide :
   Ce site a été conçu par la core team de Angular pour nous permettre d'étudier l'impact de notre montée en version en considérant quelques facteurs à savoir la version actuelle de notre projet, la version ciblée pour la mise à niveau, les différents packages maintenus par la core team de Angular que nous avons dans notre projet. Toutefois, il faut aller de façon méthodique avec les instructions que propose ce site.

2. S'assurer de la version de Node.js compatible avec la nouvelle version de Angular ciblée :
   Notre montée en version peut nous contraindre à effectuer une mise à jour de la version de Node.js utilisée. Il ne faut pas hésiter à le faire. Nous pouvons nous rendre ici Angular Version Compatibility - Node.js .

3. Exécuter la commande ng update :
   L'exécution de la commande ng update tout court n'impactera pas notre projet. Cette commande affichera dans notre terminal un terminal avec les dépendances reconnues officiellement par Angular en affichant la version actuelle et la version à atteindre pendant la mise à niveau.

4. Effectuer une montée en version progressive :
   Il est nécessaire de faire une montée en version progressive. Supposons que nous voulons faire une montée en version de Angular 9 vers Angular 16. Il est capital d'y aller pas-à-pas. D'abord, il faut faire une montée en version de 9 vers 10, ensuite de 10 vers 11 et ainsi de suite. La montée en version se fait en une ligne de commande : ng update @angular/core@[version_cible] @angular/cli@[version cible] .

5. S'assurer de la compatibilité des dépendances externes avec la version de Angular :
   Pendant la montée en version progressive, il faut s'assurer que les bibliothèques externes suivent le mouvement. A chaque montée de version, il faut s'assurer que le projet compile bien et qu'il n'y a pas de régression. Il faut vérifier au niveau de la documentation de ces bibliothèques quelle est la version compatible avec notre version de Angular cible.

6. S'attendre à faire de la réécriture de code si NgRx est utilisée :
   Si nous utilisons le gestionnaire d'état NgRx dans notre projet, nous devons vérifier de façon miticuleuse que nous n'avons pas à réécrire nos Effects par exemple. En effet, la bibliothèque dans sa mise à jour est passée des décorateurs aux fonctions create pour faciliter l'implémentation des Actions, Reducers, Effects, etc.

7. Effectuer du "forcing" quand il le faut :
   Lorsque nous rencontrons une bibliothèque développée en Angular dont le package @angular/core ou @angular/common est obsolète par rapport à ce que nous avons dans notre projet, la commande ng update énoncée dans le point 4 n'ira pas au bout. Pour y remédier, nous devons pousser un peu plus loin notre investigation. Il faut lire le code source de cette bibliothèque pour analyser les impacts lors de l'ajout de --force dans notre commande du point 4. Si notre bibliothèque qui coince n'a pas d'autres dépendances à part Angular alors il n'y aura pas d'incidence. Dans le cas contraire, il faudra réfléchir à un palliatif.

8. Lire et bien comprendre les warnings et problèmes qui s'affichent dans le terminal et la console de notre navigateur :
   Lors de la montée en version, nous devons être très attentif à ce qui s'affiche dans notre terminal et dans la console de notre navigateur.

9. Vérifier la compatibilité avec les navigateurs obsolètes :

   Après la montée en version, il y a des versions de navigateurs qui ne sont pas prises en charge. Notre application risque de ne pas fonctionner sur ces navigateurs. Nous pouvons vérifier la compatibilité ici Browser Support. Toutefois, avec BrowsersList déjà présent dans notre projet, on peut étendre les versions de navigateurs que nous souhaitons en le couplant avec les polyfills.

Pour finir, il est à souligner que la CLI (Command-Line Interface) de Angular aide beaucoup dans la montée en version. En effet, elle s'occupe même de modifier le contenu de nos fichiers quand il le faut. Beaucoup de choses se passent de façon transparente. C'est vraiment intéressant pour l'expérience développeur. Aussi, il n'est plus à rappeler, qu'il faut versionner son code. Le code même obsolète qui fonctionne déjà doit être bien conservé en cas de rollback.

En somme, nous avons fait un tour d'horizon des points essentiels pour réussir sereinement notre montée en version. La patience et la concentration sont les qualités à avoir pendant cette épreuve.

Pour plus d'informations :

👉 Angular Update Guide

👉 Angular Version Compatibility - Node.js - RxJS

👉 Browser Support

👉 BrowsersList

👉 NgRx Docs

<ul *ngFor="let item of items">
    <li> {{ item.name }} </li>
</ul>

• items est un tableau d'objets qui contient la propriété name comme un attribut de chacun de ces objets.

Supposons à présent que nous ayons une très grande liste d'éléments à afficher et qu'après affichage, nous faisons des traitements sur quelques éléments de cette liste.

Lorsque nous inspectons notre page web en utilisant le navigateur Google Chrome par exemple, une fois dans le menu Rendering puis l'option Paint Flashing, nous remarquons que tous les éléments de notre liste sont mis à jour à chaque fois, même ceux qui n'ont pas subi de modifications. Résultat, nous aurons des soucis de performance.

Heureusement pour nous, la core team de Angular y avait déjà pensé !
La solution est très simple. Il s'agit de la fonction trackBy😁

En effet, la fonction trackBy nous permet d'identifier chaque élément de façon unique dans notre DOM. Ainsi, lorsque nous modifions des éléments de notre liste, seuls ces éléments sont mis à jour et toute notre liste ne subit plus de rafraîchissement.
Voici un exemple de comment procéder en reprenant l'exemple précédent :

<ul *ngFor="let item of items; trackBy: itemTrackBy" >
    <li> {{ item.name }} </li>
</ul>

export class ItemComponent {
 ...   
    public itemTrackBy(index: number, item: Item) {
      return item.id;
    }
}

En somme, nous comprenons à présent pourquoi il est crucial de faire gaffe lorsque nous manipulons des boucles *ngFor dans nos applications Angular. C'est tout à notre avantage de permettre au DOM de pouvoir identifier de façon unique chaque élément de nos listes car nous gagnerons nettement en performance en cas de besoin.

Pour plus d'informations 👉 TrackBy Function

En programmation orientée objet, nous manipulons des objets au moyen des classes. Supposons que nous avons trois (03) classes à savoir ClassA, ClassB et ClassC comme l'illustre cet exemple de code basé sur du TypeScript :

export class ClassA {
  constructor() {
  }
}

export class ClassB {
  constructor() {
  }
}

export class ClassC {
  constructor() {
  }
}

Notre objectif ici est de créer deux (02) objets respectivement des classes ClassA et ClassB que nous utiliserons dans notre classe ClassC. Nous avons donc le code qui suit :

export class ClassC {
  objectA = new ClassA();
  objectB = new ClassB();
  constructor() {   
  }
}

Jusque-là, tout se passe bien. Supposons à présent que nos classes ClassA et ClassB contiennent des arguments dans leurs constructeurs respectifs comme l'indique le code suivant :

export class ClassA {
  constructor(args) {
  }
}

export class ClassB {
  constructor(args) {
  }
}

Ce changement au niveau de nos classes ClassA et ClassB nous contraint à modifier la façon dont nous créons nos objets dans la classe ClassC. Nous devons passer en paramètre des variables comme ceci :

export class ClassC {
  objectA;
  objectB;
  constructor(argsA, argsB) {   
   this.objectA = new ClassA(argsA);
   this.objectB = new ClassB(argsB);
  }
}

Cette façon classique de faire soulève deux (02) problèmes essentiels :

• Le premier problème c'est que le code n'est plus flexible parce que à chaque changement au niveau du constructeur de nos classes ClassA et ClassB, nous devons opérer des changements au niveau de la classe ClassC.

• Le second problème c'est que notre code ne sera plus vraiment facile à tester parce que à chaque fois que nous créerons une instance de la classe ClassC, nous aurons besoin d'indiquer les paramètres des classes ClassA et ClassB dans le constructeur de la classe ClassC.

Afin d'y remédier, l'astuce la plus simple est d'utiliser la notion d'injection de dépendances.

En reprenant l'exemple de nos trois (03) précédentes classes, nous avons ceci :

export class ClassA {
  constructor(args) {
  }
}

export class ClassB {
  constructor(args) {
  }
}

export class ClassC {
  objectA;
  objectB;
  constructor(private objectA: ClassA, private objectB: ClassB) {   
    this.objectA = objectA;
    this.objectB = objectB;
  }
}

Nous remarquons donc que les changements au niveau du constructeur de nos classes ClassA et ClassB ne nous obligent plus à modifier nos instances dans la classe ClassC.

Oui c'est magique 😂

En revenant sur notre thématique, Angular est entièrement basé sur le langage orienté objet TypeScript ce qui lui de mettre en place la notion d'injection de dépendances. Nous verrons quelques cas usuels d'utilisation de l'injection des dépendances dans nos projets :

• Utilisation des classes Router, ActivatedRoute et HttpClient :

Pour créer des instances de ces classes après avoir bien-sûr déclaré leurs modules là où il le faut, voici ce que nous faisons généralement :

export class MyComponent {
    constructor(private router: Router, private route: ActivatedRoute) {
  }
}

export class MyService() {
    constructor(private http: HttpClient) {
  }
}

Résultat, nous ne nous soucions pas de comment ces instances sont initialisées. C'est de l'injection de dépendances.

• Création d'un service :

Lorsque nous créons nos propres services, voici comment nous les utilisons dans nos composants :

export class MyComponent {
    constructor(private myService: MyService) {
  }
}

En faisant ainsi, nous exploitons la notion d'injection de dépendances. En effet, si nous remarquons bien lors de la création de nos services, nous avons le décorateur @Injectable() qui nous permet d'injecter notre service là où nous désirons l'utiliser. Généralement, nous avons ceci :

@Injectable({ provideIn: 'root' })
export class MyService() {
    constructor() {
  }
}

• provideIn permet de préciser la portée de notre service. Lorsque nous indiquons 'root' le service est créé et disponible au lancement de l'application. Nous avons aussi d'autres valeurs à savoir 'platform', 'any' et null, qui suivant le cas, nous amène à utiliser le tableau providers.

Pour finir, nous pouvons également faire de l'injection de dépendance en utilisant la fonciton inject qui a subi des mises à jour depuis Angular 14:

/* au lieu de faire ceci : */
export class MyService() {
    constructor(private http: HttpClient) {
  }
}


/* nous pouvons faire : */
export class MyService() {
   http = inject(HttpClient);
}

En somme, nous avons à présent une idée de comment Angular raisonne par rapport à l'injection de dépendance et nous comprenons davantage pourquoi nous sommes autorisés à utiliser certaines classes sans le mot clé new .

Pour plus d'informations :

👉 Understanding Dependency Injection

👉 Dependency Injection Overview in Angular

👉 Creating Injectable Service

👉 Inject Function

Supposons que tous nos composants sont déclarés dans un seul module à savoir AppModule par exemple, ce qui implique que nous avons un seul fichier de routes qui n'est rien d'autre que AppRoutingModule. Lorsque nous créons le build final du projet, nous remarquons la création d'un seul fichier Javascript qui contient toute la logique métier de notre application. En effet, au lancement de notre application web, tous les composants visibles comme invisibles à l'utilisateur sont chargés dans le navigateur ce qui crée des latences lorsque nous avons une grosse application. Cette latence est due au fait que le navigateur doit télécharger tout le bundle (fichier de build Javascript) avant d'afficher la première interface. Résultat, nous faisons face à des soucis d'expérience utilisateur.

Maintenant que le décor est bien planté, nous verrons comment gérer ça 😁

Comme vous l'aurez déjà deviné, la core team de Angular s'est penché sur le problème et ils ont trouvé une solution. Ils se sont dits ceci :

Pourquoi ne pas permettre le chargement des composants uniquement lorsque l'utilisateur demande à y avoir accès ? 🤔

C'est ainsi qu'est né le lazy-loading (chargement paresseux en français) au niveau des modules.

Pour implémenter cette technique, il faut que chacun des composants que nous voulons rendre paresseux au chargement soit associé à un module et bien évidemment autre que le module de base. En bref, chaque composant avec son module comme l'indique cette image :

Par la suite, dans notre fichier de route (AppRoutingModule par exemple), nous chargerons notre composant de façon dynamique comme ceci :

const routes: Routes = [
  {
    path: 'customers',
    loadChildren: () => import('./customers/customers.module').then(m => m.CustomersModule)
  }
];

• loadChildren permet le chargement dynamique ou asynchrone ou encore paresseux de notre composant à travers son module.

• Nous allons ensuite mettre en place un système de route dans notre composant customers et plus précisement dans un module de route propre à lui qui est CustomersRoutingModule :

    const routes: Routes = [
      {
        path: '',
        component: CustomersComponent
      }
    ];
  

En réalité, nous n'avons pas besoin de le faire manuellement. Il existe une ligne de commande qui fait le job à notre place :

ng generate module customers --route customers --module app.module

Cette commande nous créera un dossier avec six (06) fichiers à savoir :

• customers-routing.module.ts

• customers.component.html

• customers.component.scss

• customers.component.spec.ts

• customers.component.ts

• customers.module.ts

et rajoutera une route dans notre AppRoutingModule qui sera lazy-loading .

Pour finir, si nous créons un nouveau build, nous remarquerons l'existence d'un nombre de fichiers Javascript équivalent au nombre de chargement paresseux que nous avons implémenté dans notre fichier de routes AppRoutingModule. Ces fichiers sont des chunks c'est-à-dire qu'ils contiennent du code associé au module. Au lancement de l'application, seuls les composants qui sont destinés à apparaître sous les yeux de l'utilisateur se chargeront. Le constat est flagrant en inspectant le navigateur et en allant sur l'option Réseau. Au fur et à mesure que l'utilisateur décide de visiter une page, le chunk associé à cette page est téléchargé dans le navigateur. Résultat, l'application est davantage plus rapide.

En somme, il est judicieux de penser à mettre le lazy-loading dans nos applications si nous devons gérer un système de routes. Cela nous conforterait dans la rapidité d'affichage de nos applications au lancement surtout si l'utilisateur n'a pas une bonne connexion Internet. Nous avons toutefois la possibilité de définir la façon dont nous voulons effectuer notre chargement paresseux à travers des stratégies.

Pour plus d'informations 👉 Lazy-loading feature modules

Et si vous appreniez qu'il existe un autre moyen beaucoup plus simple de le faire ?
Ah bon ? 😁

Effectivement, il existe une autre façon encore plus simple d'avoir accès aux informations d'un composant depuis un autre composant.

Il s'agit de l'attribut exportAs. C'est un attribut utilisé sur les directives et donc valable également sur nos composants car un composant est avant tout une Directive.

Supposons que nous ayons un composant PersonComponent qui permet à l'utilisateur de choisir son genre :

@Component({
  selector: 'app-person',
  template: `
    <input type="radio" name="gender" [(ngModel)]="myGender" value="male" /> Male
    <input type="radio" name="gender" [(ngModel)]="myGender" value="female" /> Female
  `,
  exportAs: 'personContext'
})

export class PersonComponent {
    public myGender: string;
}

• exportAs: 'personContext' permet d'indiquer que personContext fait référence à la classe PersonComponent lorsque nous voulons l'utiliser dans notre template HTML au moyen d'une variable de référence.

Par la suite, nous avons un autre composant AvatarComponent qui est chargé d'afficher un avatar en fonction du genre de la personne :

@Component({
  selector: 'app-avatar',
  template: `
   <img *ngIf="gender === 'male'" src="avatarMale.jpg" />
   <img *ngIf="gender === 'female'" src="avatarFemale.jpg" />
  `,
})

export class AvatarComponent {
   @Input() gender: string;
}

Pour finir, dans notre composant parent AppComponent par exemple, nous aimerions interagir entre le composant PersonComponent et le composant AvatarComponent. Voici ce qu'il faut faire :

<div>
 <app-avatar [gender]="personContext.myGender"></app-avatar>
</div>
<app-person #person="personContext"></app-person>

• #person='personContext' est la variable de référence person qui a pour valeur personContext et qui n'est rien d'autre que la référence de notre composant PersonComponent.

• personContext.myGender permet d'avoir accès à la valeur de la variable myGender présent dans le composant PersonComponent.

L'attribut exportAs, nous permet d'avoir accès aux attributs et méthodes publiques de notre composant afin d'interagir avec eux. Nous remarquons que l'information myGender est partagée entre les deux composants sans que nous ayons besoin de @Output() ou d'un service.

En somme, exportAs est un attribut qui nous évite d'injecter un service ou un composant pour partager des informations entre nos composants ainsi que l'utilisation du décorateur @Output().

Pour plus d'informations👉 exportAs

Supposons que nous ayons besoin de récupérer une information qui se trouve dans l'en-tête (headers en anglais) de la réponse à notre requête. En effet, pour des raisons de sécurité ou un besoin particulier, notre backend décide de mettre des données au niveau de l'en-tête de la réponse à notre requête. Cette information peut être un token JWT (JSON Web Token), un cookie ou toute autre information cruciale pour notre logique métier.

Le service HttpClient de Angular nous offre une interface appelée HttpInterceptor qui nous permet de manipuler aisément nos requêtes avant, pendant et après leur exécution. C'est une interface très utilisée et très utile.

Voici les étapes à suivre pour récupérer une information qui se trouve au niveau de l'en-tête de la réponse :

1- Créer une classe qui implémente l'interface HttpInterceptor :

import { Injectable } from '@angular/core';
import {
  HttpInterceptor,
  HttpRequest,
  HttpHandler,
  HttpEvent
} from '@angular/common/http';

@Injectable({
  providedIn: 'root',
})

export class RequestInterceptor implements HttpInterceptor {

  intercept(request: HttpRequest<any>, 
            next: HttpHandler): Observable<HttpEvent<any>> {
  } 
}

• intercept : c'est la méthode que nous redéfinissons à travers l'interface HttpInterceptor qui nous permet d'intercepter une requête afin d'effectuer nos traitements.

• request : c'est l'objet qui représente notre requête. Nous y trouverons toutes les informations en rapport avec la requête à envoyer vers notre serveur.

• next : c'est l'objet qui nous permet de passer à l'étape suivante après nos différents traitements afin que notre requête puisse continuer son exécution après avoir été intercepté et subi des traitements.

2- Indiquer à notre module root qu'il doit utiliser cet intercepteur de requête :

import { HTTP_INTERCEPTORS } from '@angular/common/http';
....
providers: [
....
 { provide: HTTP_INTERCEPTORS, useClass: RequestInterceptor, multi: true }
....
]

• provide : cet attribut nous permet d'indiquer que le service à exploiter c'est HTTP_INTERCEPTORS.

• useClass : cet attribut nous permet d'indiquer la classe à utiliser lorsque nous voulons exploiter le service HTTP_INTERCEPTORS. Cette classe dans notre cas est RequestInterceptor.

• multi : cet attribut avec sa valeur true nous permet de faire pointer différentes classes sur notre service à exploiter HTTP_INTERCEPTORS. Nous pouvons avoir plusieurs classes d'intercepteur de requêtes qui font différents traitements.

3- Ajouter la logique suivante au niveau de la méthode intercept pour avoir accès aux informations de l'en-tête de la réponse à notre requête HTTP :

  intercept(request: HttpRequest<any>, 
            next: HttpHandler): Observable<HttpEvent<any>> {
  return next.handle(request).pipe( 
    tap((event: HttpEvent<any>) => { 
      if (event instanceof HttpResponse) { 
           console.log('Http response headers : ', event.headers); 
      } 
    }), 
    catchError((error: HttpErrorResponse) => { 
      console.log('Error ', error); 
      return throwError(error); 
    }) 
  );
}

• tap : cet opérateur RxJS nous permet de capturer un évènement HttpEvent afin de tester si cet évènement est de type HttpResponse. C'est important parce que les évènements HTTP sont multiples.

• catchError : cet opérateur RxJS nous permet de capturer les erreurs provenant de notre requête afin de les traiter convenablement.

En somme, nous avons vu ensemble comment récupérer les informations contenues dans l'en-tête d'une réponse HTTP en utilisant un intercepteur de requêtes. Le service HttpClient que Angular met à notre disposition est tellement puissant qu'il faut prendre le temps de bien l'étudier.

Pour plus d'informations :

👉HttpInterceptor

👉 HttpRequest

👉 HttpResponse

👉 HttpErrorResponse