Comment l'héritage et la compilation AOT transforment les applications Angular

Dans le monde d'Angular, l'héritage des composants et la compilation Ahead-of-Time (AOT) sont deux concepts essentiels qui contribuent à la performance et à la maintenabilité des applications modernes. L'approfondissement de ces concepts permet de mieux comprendre l'évolution du cadre de développement Angular, notamment avec l'introduction d'Ivy, le moteur de compilation de la version 9.

typescript
Copy code
import { Component, Input } from '@angular/core';

import { BaseSearchComponent } from './base-search.component';

@Component({
  selector: 'app-suggested-search',
  styleUrls: ['./base-search.scss'],
  template: `
    {{ suggestion }}
  `
})
export class SuggestedSearchComponent extends BaseSearchComponent {

  @Input() suggestions: readonly string[] = [];

}

Dans cet exemple, le composant SuggestedSearchComponent hérite du composant BaseSearchComponent. Il reprend ainsi les propriétés d'entrée (comme placeholder) et l'événement de recherche (onSearch). Ce processus permet de réutiliser efficacement le code sans dupliquer les fonctionnalités, tout en ajoutant des propriétés supplémentaires spécifiques, comme la liste des suggestions de recherche. Ce modèle de réutilisation de code est un exemple classique de l'usage de l'héritage dans la programmation orientée objet (POO), mais dans Angular, ce processus est également rendu possible grâce aux métadonnées du décorateur @Component et à la liaison de données via des templates.

Un autre aspect fondamental d'Angular est la compilation AOT (Ahead-of-Time), qui optimise la taille et la performance des applications. L'objectif principal de cette compilation est de générer des bundles plus petits et plus rapides à exécuter. En termes simples, la compilation AOT permet de convertir le code TypeScript en instructions exécutables plus légères avant que l'application ne soit lancée, ce qui réduit la taille du bundle final.

Auparavant, avec l'ancien moteur de compilation View Engine, les applications Angular avaient tendance à générer des bundles plus gros en mode JIT (Just-in-Time) que ceux générés en mode AOT. Cela avait pour conséquence que, pour les petites applications, la compilation AOT n'apportait pas toujours de gains notables. Cependant, avec l'arrivée d'Ivy, ce n'est plus le cas. Ivy permet de découper les parties inutilisées du framework (comme les animations ou la gestion de la globalisation), ce qui rend l'application plus légère et plus rapide à charger, en particulier pour les micro-frontends ou les composants web.

En plus de la réduction des tailles de bundle, Ivy introduit des optimisations en termes de localité du code. En effet, le compilateur Ivy ne compile que les parties nécessaires des composants et de leurs dépendances, ce qui rend les builds plus rapides et réduit la quantité de code générée. Cela s'explique par le fait qu'Ivy fonctionne en générant des instructions DOM plus simples et plus efficaces, contrairement à View Engine, qui nécessitait un processus de traduction plus complexe.

Une autre amélioration introduite par Ivy est la prise en charge de la configuration stricte dans le cadre de développement. En activant l'option --strict, les développeurs peuvent bénéficier de vérifications supplémentaires qui permettent de repérer plus rapidement les erreurs potentielles, comme des erreurs de typage ou des incohérences dans le code. Ces configurations sont activées par défaut depuis Angular version 12 et permettent de s'assurer que l'application est plus robuste dès sa création.

Cependant, l'adoption de ces outils n'est pas sans défis. Bien que la compilation AOT et la configuration stricte apportent de nombreux avantages, elles peuvent également augmenter le temps de construction, surtout dans des projets complexes ou lorsque des bibliothèques externes non compatibles avec Ivy sont utilisées. Dans ce cas, il est nécessaire d'utiliser le Angular Compatibility Compiler pour convertir le code d'une bibliothèque compilée avec View Engine en code compatible avec Ivy, ce qui peut ralentir les processus de construction.

En fin de compte, l'introduction d'Ivy et de la compilation AOT dans Angular représente un tournant majeur dans la manière dont les applications Angular sont construites et exécutées. L'optimisation des tailles de bundle, l'amélioration de la vitesse d'exécution et la réduction du coût en termes de ressources sont des avantages indéniables pour les applications modernes, en particulier dans des environnements où la performance est cruciale.

Le passage à Ivy et l'utilisation de la compilation AOT impliquent une prise en charge de nouvelles méthodologies et une certaine courbe d'apprentissage, mais les bénéfices à long terme, en termes de maintenabilité et de performance, sont considérables. La clé réside dans une adoption progressive des nouvelles pratiques, en particulier dans le cadre d'applications de grande envergure ou de systèmes modulaires complexes.

Quelle est l'importance du scope "any provider" dans Angular pour la gestion des dépendances et des configurations ?

Il est important de noter que, tout comme pour la notation abrégée du module racine, les dépendances fournies via cette notation abrégée de scope "any provider" sont "tree-shakables", ce qui les distingue des fournisseurs de services de module Angular classiques ou du modèle "forRoot-forChild". Dans les modèles alternatifs, la dépendance est toujours incluse, même si elle n’est pas utilisée, car une référence statique existe entre le module Angular et la dépendance. En revanche, le scope "any provider" permet d'éviter ce problème, rendant ainsi les dépendances plus optimisées et plus modulaires.

En y réfléchissant bien, le scope "any provider" est destiné à des cas d’utilisation très spécifiques. Il est principalement utile pour gérer des dépendances d'état qui varient d’un module Angular de fonctionnalité chargé paresseusement à un autre. De plus, il est pratique pour les cas d’utilisation comme l'analyse, les configurations, la journalisation et la collecte de métriques. Ce scope offre une alternative "tree-shakable" à d'autres modèles de fournisseurs dans Angular, tels que le modèle "forRoot-forChild", les fournisseurs de modules de fonctionnalités Angular paresseusement chargés et les fournisseurs de services de module Angular.

Il est également pertinent de noter qu’un service backend comme celui mentionné dans cet exemple peut tirer parti du scope "any provider" pour gérer des comportements dynamiques, tels que des tentatives de nouvelle requête (retry) avec des intervalles personnalisés. Ce comportement est essentiel dans des environnements où la résilience et la fiabilité des requêtes HTTP sont des préoccupations primordiales, comme dans les applications d'analyse ou de gestion des actions où les données changent fréquemment.

Voici un exemple d'implémentation d’un service backend qui utilise le scope "any provider" :

typescript
Copy code
import { HttpClient } from '@angular/common/http';

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

import { Observable } from 'rxjs';
import { BackendConfiguration } from './backend-configuration';
import { backendConfigurationToken } from './backend-configuration.token';

import { BackendGetOptions } from './backend-get-options';

import { retryWithDelay } from './retry-with-delay.operator';
@Injectable({
  providedIn: 'any',
})
export class BackendService {
  constructor(
    @Inject(backendConfigurationToken)
    private configuration: BackendConfiguration,
    private http: HttpClient
  ) {}
  get(url: string, options: BackendGetOptions = {}): Observable<any> {
    return this.http
      .get(`${this.configuration.baseUrl}/${url}`, {
        ...options,
        responseType: 'json',
      })
      .pipe(
        retryWithDelay(
          this.configuration.retryAttempts,
          this.configuration.retryIntervalMs
        )
      );
  }
}

Il est également crucial de bien comprendre la notion d'injecteur de module et comment les différentes instances de services sont partagées ou isolées en fonction du scope. Ce mécanisme assure une gestion fine des ressources et des comportements dans des applications complexes où les configurations peuvent changer en fonction des modules chargés paresseusement ou des modules principaux.