Questions d’entretien Angular

Puis allez plus loin

• Vous n’écrivez plus standalone: true — c’est le défaut. Chaque composant importe exactement ce que son template utilise (d’autres composants, des pipes, RouterLink), si bien que les dépendances sont explicites et compatibles avec le tree-shaking.
• La configuration globale de l’application vit dans app.config.ts, sous forme de providers : provideRouter(routes), provideHttpClient(...) seulement si vous le configurez, etc.
• Une ancienne bibliothèque qui n’exporte qu’un NgModule peut quand même aller directement dans les imports d’un composant ; les providers du module passent par importProvidersFrom().

import { bootstrapApplication } from '@angular/platform-browser';
import { App } from './app/app';
import { appConfig } from './app/app.config';

bootstrapApplication(App, appConfig).catch((err) => console.error(err));

Puis allez plus loin

• [disabled] lie une propriété du DOM ; pour ce qui n’existe que comme attribut (ARIA, colspan), on utilise [attr.aria-label].
• [(x)] (« banana in a box ») est du sucre syntaxique pour [x]="v()" + (xChange)="v.set($event)". Avec un signal, on passe le signal lui-même, sans parenthèses.
• Les expressions de template doivent être légères et sans effet de bord ; la lecture d’un signal comme count() est acceptable, mais l’appel d’une méthode coûteuse s’exécute à chaque vérification.

<h2>{{ user().name }}</h2>
<img [src]="user().avatarUrl" [attr.aria-label]="user().name" />
<button [disabled]="saving()" (click)="save()">Save</button>
<input (input)="query.set($any($event.target).value)" />
<app-toggle [(checked)]="notifications" />

Puis allez plus loin

• Trackez par un identifiant unique et stable (track user.id) ; $index seulement pour les listes statiques ; tracker l’objet lui-même signifie que chaque nouvelle requête détruit et recrée le DOM.
• Il fait partie du langage : aucun import de NgIf/NgFor. @for expose $index, $first, $last, $even, $odd, $count.
• @if (user(); as u) fournit un alias typé et non nul. Depuis la v21.1, plusieurs @case peuvent partager un bloc, et @default never; (v21.2) transforme un cas d’union oublié en erreur de compilation.

@if (tasks().length) {
  <ul>
    @for (task of tasks(); track task.id; let i = $index) {
      <li>{{ i + 1 }}. {{ task.title }}</li>
    }
  </ul>
} @else {
  <p>You have no tasks.</p>
}

Puis allez plus loin

• Elle ne peut pas être réaffectée depuis le template ; elle est recalculée quand ce qu’elle lit change.
• Elle est pratique dans @for pour une valeur propre à chaque élément (p. ex. un prix final après remise).
• La vraie logique appartient toujours à la classe, sous forme de computed() ; @let sert la lisibilité, pas les règles métier.

Puis allez plus loin

• [class] accepte une chaîne, un tableau ou un objet ; [style] accepte une chaîne ou un objet, et les unités se placent dans le binding (.px, .%, .rem).
• [ngClass]/[ngStyle] sont l’ancienne méthode ; la v21 propose les migrations ngclass-to-class et ngstyle-to-style.
• Pour l’élément hôte du composant lui-même, on utilise les métadonnées host ('[class.is-loading]': 'loading()'), pas @HostBinding.

Puis allez plus loin

• Les pipes sont standalone et s’importent comme n’importe quelle dépendance (imports: [DatePipe]) ; une pipe personnalisée est une classe avec @Pipe et transform().
• Comme la vérification se fait par référence, une pipe pure ne se réexécute pas si vous mutez un tableau sur place.
• Une méthode appelée depuis le template s’exécute à chaque vérification ; pour les calculs propres à un composant, préférez computed(), et réservez les pipes au formatage d’affichage réutilisable. Évitez pure: false.

Puis allez plus loin

• Un input() est un signal en lecture seule : on le lit avec value() et on en dérive avec computed() — pas besoin de ngOnChanges.
• input.required<T>() transforme un binding manquant en erreur de compilation ; transform: numberAttribute / booleanAttribute convertissent max="10" ou un simple attribut readonly vers le bon type.
• L’enfant ne peut pas faire set() sur son propre input. S’il doit changer la valeur, il émet un événement et laisse le parent décider, ou utilise model().

export class StarRating {
  readonly value = input.required<number>();
  readonly max = input(5, { transform: numberAttribute });
  readonly rate = output<number>();

  protected readonly stars = computed(() =>
    Array.from({ length: this.max() }, (_, i) => i + 1),
  );
}

Puis allez plus loin

• Utilisez model() quand la valeur appartient vraiment aux deux côtés, comme dans un toggle, un stepper ou un champ personnalisé.
• Utilisez input() + output() quand l’enfant ne fait que proposer et que le parent décide (valide, confirme, enregistre côté serveur).
• Dans un two-way binding, on passe le signal lui-même (notifications), pas sa valeur (notifications()).

Puis allez plus loin

• select accepte un sélecteur de balise, d’attribut ou de classe ([card-title]) ; le <ng-content /> sans select récupère tout le reste, et vous pouvez y mettre un contenu de repli.
• Piège : le contenu projeté est créé par le parent même si l’enfant le masque avec @if. Pour un contenu vraiment lazy, passez un <ng-template>.
• La projection convient au markup flexible (layouts, cartes, boîtes de dialogue) ; les inputs servent aux données que le composant met lui-même en forme.

Puis allez plus loin

• Les dépendances sont suivies automatiquement : tous les signaux lus par la fonction deviennent des dépendances, sans abonnement à gérer.
• Les signaux se comparent avec === : items().push(x) ne notifie personne ; utilisez update((list) => [...list, x]).
• Règle empirique : tout ce qui peut être calculé à partir d’un autre état est un computed(), pas un second signal à garder synchronisé. Exposez l’état avec asReadonly().

export class Counter {
  protected readonly count = signal(0);
  protected readonly double = computed(() => this.count() * 2);

  protected increment() {
    this.count.update((c) => c + 1);
  }
}
// template: {{ count() }} · {{ double() }}

Puis allez plus loin

• N’utilisez pas un effect pour copier un signal dans un autre : c’est un computed() (ou un linkedSignal() s’il doit aussi être modifiable).
• Ne récupérez pas de données depuis un effect : il n’y a pas d’annulation et d’anciennes réponses peuvent gagner la course. Utilisez httpResource() / resource().
• Il doit être créé dans un contexte d’injection (constructeur ou champ), il est détruit avec le composant, et onCleanup nettoie les timers avant l’exécution suivante.

Puis allez plus loin

• Lire un input.required() dans le constructeur lève une erreur, car le parent ne l’a pas encore lié. Avec les signal inputs, ngOnInit est rarement nécessaire : un computed() ou un httpResource() lit l’input quand il est prêt.
• inject() ne fonctionne pas dans ngOnInit ni dans un gestionnaire de clic — c’est hors du contexte d’injection (erreur NG0203).
• DestroyRef fonctionne aussi dans les services, les directives et les fonctions réutilisables, ce que ngOnDestroy ne peut pas faire. Pour accéder au DOM après le rendu, utilisez afterNextRender().

export class Clock {
  readonly now = signal(new Date());

  constructor() {
    const id = setInterval(() => this.now.set(new Date()), 1000);
    inject(DestroyRef).onDestroy(() => clearInterval(id));
  }
}

Puis allez plus loin

• @Service() équivaut à @Injectable({ providedIn: 'root' }) : créé à la première injection et compatible avec le tree-shaking. Il impose inject() — la DI par constructeur est une erreur de compilation.
• @Injectable reste valide (code existant, bibliothèques pour des versions plus anciennes). Placer le service dans les providers d’un composant donne une instance par composant au lieu d’une par application.
• inject() fonctionne aussi dans les guards fonctionnels, les resolvers et les interceptors, et évite les longs appels super(...) avec l’héritage.

@Service()
export class CartService {
  private readonly _items = signal<CartItem[]>([]);
  readonly items = this._items.asReadonly();
  readonly count = computed(() => this._items().length);

  add(item: CartItem) {
    this._items.update((list) => [...list, item]);
  }
}

Puis allez plus loin

• loadComponent: () => import('./home-page') place la page dans un chunk séparé, téléchargé seulement quand la route est visitée ; loadChildren fait de même pour toute une fonctionnalité.
• L’ordre compte — la première correspondance l’emporte — donc le wildcard '**' va en dernier. routerLinkActive ajoute une classe au lien actif.
• Utilisez routerLink, pas href : href recharge toute l’application.

Puis allez plus loin

• Piège : naviguer de /products/1 à /products/2 réutilise la même instance de composant ; le code qui lit l’id une seule fois (p. ex. un snapshot dans ngOnInit) affiche des données périmées.
• Les paramètres sont des chaînes dans l’URL, donc un transform comme numberAttribute vous donne un vrai nombre.
• Depuis la v22, les routes enfants héritent par défaut des paramètres et des données de tous leurs parents (paramsInheritanceStrategy: 'always').

@Component({ templateUrl: './product-page.html' })
export default class ProductPage {
  readonly id = input.required({ transform: numberAttribute }); // :id
  readonly tab = input<'specs' | 'reviews'>('specs');           // ?tab=

  readonly product = httpResource<Product>(() => '/api/products/' + this.id());
}

Puis allez plus loin

• L’Observable est cold : aucune requête n’est envoyée tant que personne ne s’abonne (subscribe(), firstValueFrom(), la pipe async).
• Pour des lectures réactives dans un composant, httpResource() fournit value(), isLoading() et error() sous forme de signaux et annule les anciennes requêtes ; pour les écritures (POST, PUT), on appelle HttpClient.
• Le générique get<T> n’est qu’une assertion de type, pas une validation. En v22, Fetch est le backend par défaut ; les préoccupations transverses (jeton d’authentification, erreurs) vont dans des interceptors fonctionnels.

Puis allez plus loin

• Le signal du modèle est la source de vérité — pas de copie interne, pas de patchValue : model.set(data) remplit le formulaire, et le formulaire écrit directement dans le modèle.
• L’état de chaque champ est fait de signaux : f.email().invalid(), touched(), errors() ; le formulaire entier est aussi un champ (f().valid(), f().submitting()).
• Affichez les erreurs seulement après touched(), et validez toujours aussi côté serveur — la validation côté client relève de l’UX, pas de la sécurité.

export class LoginForm {
  readonly model = signal({ email: '', password: '' });

  readonly loginForm = form(this.model, (p) => {
    required(p.email);
    email(p.email);
    minLength(p.password, 8);
  });
}
// template: <input [formField]="loginForm.email" />

Puis allez plus loin

• @placeholder s’affiche avant le déclencheur (requis pour on viewport / interaction / hover), @loading pendant le téléchargement, @error si le téléchargement échoue.
• Piège : si un composant différé est aussi référencé ailleurs dans le même fichier (hors du bloc), il est chargé immédiatement et le chunk est perdu.
• prefetch on hover télécharge tôt et affiche plus tard — idéal pour les actions « à un clic ».

@defer (on viewport) {
  <app-comments [postId]="post().id" />
} @placeholder {
  <div class="comments-skeleton"></div>
} @loading (after 100ms) {
  <app-spinner />
}

Puis allez plus loin

• Sans zone.js, un setTimeout ou un subscribe() qui modifie un simple champ ne met pas l’interface à jour. La solution est un signal (ou toSignal() / la pipe async).
• Un composant OnPush n’est vérifié que lorsqu’un input reçoit une nouvelle référence, qu’un événement s’y produit, qu’un signal qu’il lit change, ou qu’il est marqué pour vérification — sinon son sous-arbre est ignoré.
• ChangeDetectionStrategy.Eager est l’ancien comportement « toujours vérifier » (Default est déprécié) ; ng update l’ajoute là où c’est nécessaire.

Puis allez plus loin

• Testez le comportement que voit l’utilisateur (texte, clics, outputs émis), pas les détails d’implémentation privés.
• Les inputs peuvent être passés comme signaux avec inputBinding() ; les outputs sont espionnés avec outputBinding() et vi.fn().
• Pour le HTTP, utilisez provideHttpClientTesting() et HttpTestingController plutôt qu’un vrai serveur ; les services et les signal stores se testent avec TestBed.inject() et sans DOM.

it('shows the right number of stars', async () => {
  const fixture = TestBed.createComponent(StarRating, {
    bindings: [inputBinding('value', () => 3)],
  });
  await fixture.whenStable();

  const stars = fixture.nativeElement.querySelectorAll('button');
  expect(stars).toHaveLength(5);
});

Puis allez plus loin

• Définir un signal dans un effect, c’est une exécution supplémentaire, un moment où la cible est périmée (un rendu avec une valeur erronée) et un graphe de dépendances difficile à suivre.
• Les effects ne sont pas synchrones : définissez un signal trois fois et l’effect s’exécute une seule fois, avec la valeur finale. Les effects de composant s’exécutent pendant la Change Detection ; ceux des services root s’exécutent comme microtâches.
• Les dépendances sont dynamiques : seuls les signaux lus lors de la dernière exécution sont suivis. Utilisez untracked() pour les lectures qui ne doivent pas redéclencher l’effect.
• Un effect a besoin d’un contexte d’injection (constructeur ou initialiseur de champ) ou d’un injector explicite ; sinon vous obtenez NG0203. Utilisez onCleanup pour les timers et les listeners.
• Du HTTP depuis un effect est un mauvais signe : pas d’annulation, donc les réponses peuvent arriver dans le désordre. C’est précisément le rôle de resource / httpResource.

readonly firstName = signal('Ana');
readonly lastName = signal('Pop');

// ✗ effect used to synchronise state
// effect(() => this.fullName.set(this.firstName() + ' ' + this.lastName()));

// ✓ derived state
readonly fullName = computed(() => this.firstName() + ' ' + this.lastName());

// ✓ effect: reactive world → outside world
constructor() {
  effect(() => localStorage.setItem('name', this.fullName()));
}

Puis allez plus loin

• Il remplace le schéma fragile signal + effect : pas d’exécution supplémentaire, pas de rendu avec une valeur périmée.
• La forme longue (source + computation) vous donne la valeur previous, ce qui permet de conserver le choix de l’utilisateur s’il existe encore dans la nouvelle liste.
• Un set() manuel n’est valable que jusqu’au prochain changement de la source ; ensuite, c’est la computation qui l’emporte.
• Depuis la v22.1, l’option set intercepte les écritures, p. ex. pour plafonner une quantité au stock disponible.

Puis allez plus loin

• resource reçoit un abortSignal dans le loader ; httpResource passe par HttpClient, donc les interceptors s’appliquent ; rxResource prend un flux Observable et se comporte comme switchMap.
• Renvoyer undefined depuis params donne le statut idle : le loader ne s’exécute pas. En v22, vous pouvez aussi lever ResourceParamsStatus.IDLE / LOADING, et chaîner des resources avec ctx.chain().
• hasValue() est un type guard ; defaultValue supprime undefined ; parse valide ou transforme la réponse (p. ex. DTO → modèle, Zod).
• Les resources servent à la lecture. Les écritures (POST/PUT/DELETE) passent par HttpClient, puis vous faites un update() local du resource (optimiste) ou un reload().

readonly userId = input.required<number>();

// a new id → the old request is cancelled, a new one starts
readonly user = httpResource<User>(() => '/api/users/' + this.userId());

// template:
// @if (user.isLoading()) { <app-spinner /> }
// @if (user.error()) { <button (click)="user.reload()">Retry</button> }
// @else if (user.hasValue()) { <h2>{{ user.value().name }}</h2> }

Puis allez plus loin

• debounced() renvoie un Resource : value() se met à jour après le dernier changement, et isLoading() vaut true tant que l’utilisateur tape encore.
• Il est expérimental en v22. L’alternative classique est toSignal(toObservable(query).pipe(debounceTime(300), distinctUntilChanged())) : trois conversions pour un seul debounce.
• wait peut être une fonction, p. ex. pas de délai quand le champ est vidé.
• Dans les Signal Forms, il existe une règle dédiée debounce(path.field, 300), et validateHttp a sa propre option debounce.

import { httpResource } from '@angular/common/http';
import { debounced, signal } from '@angular/core';

export class UserSearch {
  readonly query = signal('');
  readonly search = debounced(this.query, 300);

  readonly users = httpResource<UserDto[]>(
    () => '/api/users?q=' + encodeURIComponent(this.search.value()),
    { defaultValue: [] },
  );
}

Puis allez plus loin

• toSignal() sans initialValue est typé T | undefined ; requireSync: true ne fonctionne que si la source émet de façon synchrone (p. ex. un BehaviorSubject).
• toObservable() émet de façon asynchrone (via un effect) et uniquement la dernière valeur si le signal est modifié plusieurs fois dans le même tick — ce n’est pas un flux d’événements.
• takeUntilDestroyed() sans argument ne fonctionne que dans un contexte d’injection ; ailleurs, passez explicitement inject(DestroyRef). Pour un nettoyage hors RxJS, utilisez DestroyRef.onDestroy().
• Gardez RxJS pour les websockets, la combinaison de flux d’événements, le retry/backoff et les politiques d’aplatissement (switchMap, exhaustMap…). Les signaux n’ont aucune notion du temps.

Puis allez plus loin

• Choisir l’opérateur, c’est choisir une politique de concurrence ; un mauvais choix cause de vrais bugs : des commandes en double avec mergeMap sur un bouton de paiement, des sauvegardes perdues avec switchMap sur une sauvegarde automatique.
• mergeMap accepte une limite de concurrence, p. ex. mergeMap(upload, 3).
• Mettez catchError dans le pipe interne : après l’opérateur d’aplatissement, la première erreur termine le flux externe et la recherche « meurt ».
• Avec les signaux, httpResource et rxResource vous donnent déjà la sémantique de switchMap pour les lectures.

// the last one wins; errors handled INSIDE, so the stream survives
query$.pipe(
  debounceTime(300),
  switchMap((q) => this.api.search(q).pipe(catchError(() => of([])))),
);

files$.pipe(mergeMap((file) => this.api.upload(file), 3)); // parallel, max 3
patches$.pipe(concatMap((patch) => this.api.save(patch))); // in order
submit$.pipe(exhaustMap(() => this.api.login(this.credentials()))); // ignore double clicks

Puis allez plus loin

• Depuis la v22, les composants sans changeDetection sont OnPush ; l’ancien comportement est ChangeDetectionStrategy.Eager (Default est déprécié). ng update ajoute Eager là où c’est nécessaire.
• Un composant OnPush n’est vérifié que pour une nouvelle référence d’input (===), un événement en lui ou dans ses enfants, un signal lu dans son template, la pipe async, ou markForCheck(). Sinon, tout le sous-arbre est ignoré.
• Muter un tableau passé en input (push) ne change pas la référence : faites des mises à jour immuables.
• markForCheck() est la rustine d’urgence pour les callbacks hérités ; detectChanges() est synchrone et rarement nécessaire.

// ✗ works with zone.js, NOT zoneless + OnPush
// now = new Date();
// setInterval(() => (this.now = new Date()), 1000);

// ✓ a signal schedules change detection by itself
export class Clock {
  readonly now = signal(new Date());

  constructor() {
    const id = setInterval(() => this.now.set(new Date()), 1000);
    inject(DestroyRef).onDestroy(() => clearInterval(id));
  }
}

Puis allez plus loin

• viewChild cherche dans le template propre du composant ; contentChild cherche dans ce que le parent a projeté (p. ex. un conteneur Tabs qui découvre ses enfants Tab).
• contentChildren ne regarde que les enfants directs par défaut ; utilisez descendants: true pour des correspondances plus profondes.
• read choisit ce que vous obtenez : ElementRef, TemplateRef, ViewContainerRef, une directive ou (v22.2) l’Injector de l’enfant.
• Piège : interroger un composant par son type dans la classe le rend eager, donc il ne sera pas séparé par un bloc @defer.

Puis allez plus loin

• Envelopper ng-content dans @if masque le DOM, mais les composants projetés existent déjà et leur lifecycle a déjà tourné.
• Les emplacements nommés utilisent select (balise, attribut, classe) ; ngProjectAs projette plusieurs éléments dans un même emplacement sans wrapper.
• Le contexte renvoie des données : $implicit correspond à let-item. Sans directive avec ngTemplateContextGuard, les variables let- sont de type any.
• Un template voit l’injector de l’endroit où il est déclaré ; depuis la v21.2, [ngTemplateOutletInjector]="'outlet'" lui fait utiliser l’injector de l’endroit où il est rendu.

@Component({
  selector: 'app-collapsible',
  imports: [NgTemplateOutlet],
  template: `
    <button (click)="open.set(!open())">Toggle</button>
    @if (open()) { <ng-container [ngTemplateOutlet]="content() ?? null" /> }
  `,
})
export class Collapsible {
  readonly content = contentChild(TemplateRef); // created only when opened
  readonly open = signal(false);
}
// <app-collapsible><ng-template><app-heavy-report /></ng-template></app-collapsible>

Puis allez plus loin

• Le signe du composant fourre-tout : des données any[], des flags isProductTable, 30 inputs et de la connaissance métier dans shared/.
• Les templates de cellule sont trouvés avec contentChildren() sur une directive ; ngTemplateContextGuard type let-row en T au lieu de any.
• Passez le comportement sous forme de fonctions (trackBy, displayWith, compareWith) pour que le composant n’ait pas à connaître la forme des données.
• Une faute de frappe dans une clé de colonne devient une erreur de compilation, pas une colonne vide en production.

Puis allez plus loin

• Un registre de loaders () => import(…) fait de chaque widget un chunk lazy distinct.
• inputBinding('title', () => …) est réactif, contrairement à l’ancien setInput() qu’il fallait rappeler à chaque changement, avec en plus des abonnements manuels aux outputs.
• ComponentFactoryResolver a été supprimé en v22 : on passe directement la classe à createComponent.
• Pour les toasts et boîtes de dialogue hors de l’arbre, utilisez le createComponent() standalone avec un EnvironmentInjector, puis appRef.attachView() pour qu’il rejoigne la Change Detection, et détruisez-le vous-même.

private readonly vcr = inject(ViewContainerRef);

private async render(type: WidgetType) {
  const component = await WIDGET_REGISTRY[type](); // lazy chunk
  this.vcr.clear();
  this.vcr.createComponent(component, {
    bindings: [
      inputBinding('title', () => this.config().title), // stays in sync
      outputBinding('remove', () => this.removed.emit(this.config().id)),
    ],
  });
}

Puis allez plus loin

• Délimitez par durée de vie : l’état d’une fonctionnalité dans les providers de la page ou de la route (il meurt avec elle), l’état global (utilisateur, panier, thème) dans un @Service() root.
• Les données serveur vont dans un httpResource à l’intérieur du store ; l’état qui doit survivre à un rafraîchissement ou être partageable va dans l’URL (query params + input()).
• Un composant dumb peut avoir un état d’UI local et injecter des éléments d’UI (ElementRef, DestroyRef), mais jamais de services de données ni le routeur — sinon il n’est ni réutilisable ni facile à tester, et une liste de 50 cartes fait 50 requêtes.
• NgRx SignalStore devient intéressant quand l’équipe veut des conventions, des plugins et des devtools, pas par défaut.

Puis allez plus loin

• @Service() (v22) équivaut à providedIn: 'root', est compatible avec le tree-shaking et n’autorise que inject(). autoProvided: false vous oblige à le lister dans providers.
• inject() l’emporte sur la DI par constructeur : pas de chaînes super(…), il fonctionne dans les guards, les interceptors et les factories, et permet des fonctions injectX() réutilisables. Il exige un contexte d’injection (sinon NG0203).
• useClass, useValue, useFactory, useExisting et multi: true pour les tableaux de type plugin ; optional, self, skipSelf, host modifient la recherche.
• Les viewProviders sont invisibles pour le contenu projeté ; les EnvironmentProviders (provideX()) ne peuvent aller qu’au niveau de l’application ou de la route, pas dans un composant.

Puis allez plus loin

• Renvoyez true/false, un UrlTree ou un RedirectCommand (redirection + options de navigation comme replaceUrl) ; depuis la v22.2, vous pouvez aussi lever un RedirectCommand.
• Resolver : la page apparaît avec ses données prêtes, mais la navigation attend et une erreur l’annule. httpResource : navigation instantanée, chargement et erreur sont de l’état d’UI.
• Avec withComponentInputBinding(), les données résolues, les params et les query params arrivent sous forme d’input().
• Les guards relèvent de l’UX, pas de la sécurité : l’API doit aussi faire respecter l’autorisation. canDeactivate protège les modifications non enregistrées.

Puis allez plus loin

• N’attachez le jeton qu’à votre propre API (vérifiez l’URL), jamais à des hôtes tiers.
• L’ordre compte : les requêtes traversent les interceptors dans l’ordre indiqué, les réponses reviennent dans l’ordre inverse.
• Appelez inject() en haut de la fonction, pas dans des callbacks RxJS comme catchError qui s’exécutent plus tard, hors du contexte d’injection.
• Utilisez HttpContextToken pour les métadonnées par requête (p. ex. ignorer la barre de chargement) plutôt que de faux en-têtes. httpResource et validateHttp passent aussi par les interceptors.

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const token = inject(AuthStore).token();
  if (!token || !req.url.startsWith('/api')) return next(req);

  return next(req.clone({ setHeaders: { Authorization: 'Bearer ' + token } }));
};

// app.config.ts
provideHttpClient(withInterceptors([authInterceptor, errorInterceptor]));

Puis allez plus loin

• @boundary (v22.2, developer preview) possède des blocs @error (let e = $error; let reset = $reset), éventuellement avec des conditions when — la première correspondance l’emporte.
• @boundary n’intercepte que les erreurs de rendu, pas celles des gestionnaires d’événements ni du code asynchrone — celles-ci atteignent toujours l’ErrorHandler.
• provideBrowserGlobalErrorListeners() transmet window.onerror et les rejets non gérés à l’ErrorHandler.
• Un interceptor doit relancer l’erreur (throwError(() => err)) après sa réaction transverse, afin que l’appelant puisse encore réagir. Les erreurs de validation ne sont pas des exceptions : elles vivent dans les errors() du formulaire.

@boundary {
  <app-price-widget [price]="price()" />
  <app-recommendations />
} @error (let e = $error; when e instanceof PermissionError) {
  <p>You don't have access to this widget.</p>
} @error (let e = $error; let retry = $reset) {
  <app-error-card [message]="e.message" (retry)="retry()" />
}

Puis allez plus loin

• Pas de copie interne : model.set() met à jour les inputs et la saisie met à jour le modèle — ni patchValue ni valueChanges.
• Les règles entre champs utilisent valueOf() dans validate ; les règles conditionnelles utilisent when, hidden, disabled (les champs masqués et désactivés ne sont pas validés) ; les règles réutilisables utilisent schema() + apply().
• validateHttp passe par HttpClient (donc les interceptors s’appliquent) et possède une option debounce en v22 ; validateAsync fonctionne avec n’importe quel resource. pending() vaut true pendant son exécution.
• Les erreurs serveur issues de submission.action peuvent être renvoyées avec un fieldTree afin d’atterrir sur le bon champ.
• La migration peut être progressive avec SignalFormControl et compatForm ; les Reactive Forms typés (nonNullable, getRawValue()) restent valides pour le code existant.

readonly model = signal({ username: '', password: '' });

readonly signup = form(this.model, (p) => {
  required(p.username);
  minLength(p.password, 8, { message: 'At least 8 characters' });
  validateHttp(p.username, {
    request: ({ value }) => '/api/username-available?username=' + value(),
    debounce: 400,
    onSuccess: (res: { available: boolean }) =>
      res.available ? undefined : { kind: 'taken', message: 'Username taken' },
    onError: () => ({ kind: 'network', message: 'Could not verify' }),
  });
});

Puis allez plus loin

• Les inputs facultatifs comme disabled, invalid, touched sont renseignés automatiquement par le formulaire — ne déclarez que ceux que vous utilisez. En v22, un output touch signale que l’utilisateur a touché le contrôle.
• Les contrôles booléens implémentent FormCheckboxControl avec checked à la place de value.
• Un CVA nécessite quatre méthodes (writeValue, registerOnChange, registerOnTouched, setDisabledState) et vous devez appeler onChange vous-même ; oublier onTouched casse « afficher les erreurs après le touch ».
• Interopérabilité en v22 : les Signal Forms peuvent lier des CVA, et les formulaires template/reactive supportent FormValueControl, donc un même contrôle peut servir aux deux pendant la migration.

Puis allez plus loin

• Référencer un composant différé dans la classe (p. ex. viewChild(HeavyChart)) ou ailleurs dans le template le rend eager.
• @placeholder s’affiche avant le déclencheur (et c’est l’élément observé pour viewport / interaction / hover sans cible) ; @loading (after 100ms; minimum 500ms) évite le scintillement ; @error gère l’échec du téléchargement d’un chunk.
• when ne se déclenche qu’une fois ; plusieurs déclencheurs se combinent avec un OU.
• Nouveau : on viewport({ rootMargin: '200px' }) (v21), on idle(500) (v22). Avec le SSR, les déclencheurs hydrate on … donnent l’incremental hydration, activée par défaut en v22.

@defer (on viewport; prefetch on idle) {
  <app-comments [postId]="post().id" />
} @placeholder (minimum 300ms) {
  <div class="comments-skeleton"></div>
} @loading (after 100ms; minimum 500ms) {
  <app-spinner />
} @error {
  <p>We couldn't load the comments.</p>
}

@defer (on interaction; prefetch on hover) {
  <app-share-dialog />
} @placeholder { <button>Share</button> }

Puis allez plus loin

• Vitest est le runner par défaut depuis la v21 (@angular/build:unit-test) ; Karma est déprécié. Utilisez vi.fn() pour les espions d’outputs et vi.useFakeTimers() à la place de fakeAsync.
• Modifier le signal lié met à jour l’input comme dans un vrai parent — pas besoin de setInput().
• Les signal stores sont les plus faciles à tester : TestBed.inject(), appelez les méthodes, vérifiez les computed(). Les effects s’exécutent de façon asynchrone, donc videz-les avec TestBed.tick().
• Testez le comportement via le DOM ou des harnesses, pas via des champs privés. TestBed.createDirective() (v22.2) teste une directive sans hôte écrit à la main.

beforeEach(() => {
  TestBed.configureTestingModule({ providers: [provideHttpClient(), provideHttpClientTesting()] });
  api = TestBed.inject(ProductsApi);
  http = TestBed.inject(HttpTestingController);
});

afterEach(() => http.verify()); // no unexpected requests

it('maps DTO → Product', async () => {
  const result = firstValueFrom(api.get(1));
  http.expectOne('/api/products/1').flush({ id: 1, name: 'Mouse', price: 99, stock: 0 });
  expect(await result).toEqual({ id: 1, name: 'Mouse', price: 99, inStock: false });
});

Puis allez plus loin

• Les dépendances sont dynamiques : à chaque exécution, la liste des producteurs est reconstruite à partir de ce qui a réellement été lu, donc un signal lu uniquement dans une branche if inactive ne déclenche rien.
• L’égalité arrête la propagation : la version n’augmente que si la nouvelle valeur n’est pas égale (Object.is par défaut). Un computed dont le résultat ne change pas ne réveille pas ses consommateurs ; { equal } personnalise cela pour les valeurs recréées depuis le serveur.
• Conséquence : la mutation (items().push()) ne notifie personne, car la référence et la version restent identiques. L’immuabilité n’est pas une question de style, c’est ainsi que le graphe détecte le changement.
• Les effects sont asynchrones et planifiés avec la Change Detection (effects de vue avant la vérification de leur composant, effects root avant tous les composants). Les signaux ne sont pas un mécanisme d’événements et n’ordonnent pas les effets de bord dans le temps — c’est le territoire de RxJS.

const a = signal(1);
const b = signal(2);
const sum = computed(() => a() + b());
const product = computed(() => a() * b());
const result = computed(() => sum() + product()); // diamond

a.set(5);
b.set(3);  // push: versions bump, nothing is recalculated yet
result();  // pull: sum, product, result run once each, with consistent values

// equality cutoff: a new array with the same content does not propagate
const ids = signal<number[]>([], {
  equal: (x, y) => x.length === y.length && x.every((v, i) => v === y[i]),
});

Puis allez plus loin

• Le template est un consommateur réactif : quand un signal qu’il a lu change, Angular marque cette vue pour rafraîchissement (comme markForCheck) et la Change Detection n’atteint que les composants concernés.
• OnPush compare les inputs par référence (===) : muter un objet passé via un input ne met pas l’enfant à jour — la même règle d’immuabilité que pour les signaux.
• Le bug classique : un simple champ modifié dans setTimeout, subscribe() ou un callback tiers (WebSocket, Maps) — « ça ne se met à jour qu’après un clic quelque part ». La solution est un signal ou toSignal() ; markForCheck() est la porte de secours pour le code hérité.
• detectChanges() est synchrone et rarement nécessaire (mesures, tests) ; markForCheck() est la variante asynchrone recommandée.

// ✗ worked with zone.js, does nothing zoneless + OnPush
export class Clock {
  now = new Date();
  constructor() {
    setInterval(() => (this.now = new Date()), 1000);
  }
}

// ✓ the signal tells Angular what changed
export class Clock {
  readonly now = signal(new Date());
  constructor() {
    const id = setInterval(() => this.now.set(new Date()), 1000);
    inject(DestroyRef).onDestroy(() => clearInterval(id));
  }
}

Puis allez plus loin

• Commencez par un inventaire : champs simples modifiés dans des callbacks asynchrones, subscribe() vers des champs, bibliothèques qui attendent NgZone.onStable. Angular 21 fournit un outil d’analyse (onpush_zoneless_migration, via le serveur MCP de la CLI, ng mcp).
• Migrez d’abord les composants feuilles, fonctionnalité par fonctionnalité : supprimez Eager, déplacez l’état vers des signaux / toSignal(), relisez et testez. Chaque PR est petite et réversible.
• Jusqu’à la fin, conservez provideZoneChangeDetection({ eventCoalescing: true }) et le polyfill zone.js ; puis retirez les deux et surveillez les bugs de type « ça ne se met à jour qu’après un clic ».
• Les tests changent aussi : fakeAsync a besoin de zone.js, passez donc à await fixture.whenStable() et aux fake timers de Vitest.
• En équipe : une règle de lint/relecture imposant les signaux pour l’état de template dans le nouveau code, et une courte checklist dans le template de PR, pour que la zone migrée ne régresse pas.

Puis allez plus loin

• Gardez l’état au niveau le plus bas qui en a besoin (composant → fonctionnalité → global) et ne le remontez que lorsqu’un nouveau consommateur apparaît. L’état d’une page est fourni sur la route ou le composant, pas en root, pour qu’il ne « colle » pas d’une visite à l’autre.
• Les données serveur sont un cache, pas votre état : gardez-les dans httpResource/resource et rechargez après les écritures. L’URL est aussi de l’état (filtres, pagination).
• Des règles qui passent à l’échelle : exposer des signaux en lecture seule (asReadonly()), une seule source de vérité avec le reste dérivé, pas de stores qui s’injectent mutuellement de façon circulaire — cela signale généralement une façade manquante ou un concept mal placé.
• Avec SignalStore, seules les méthodes appellent patchState, rxMethod gère les flux asynchrones (avec catchError dans le flux interne) et signalStoreFeature supprime le code de chargement/erreur copié-collé. Les bibliothèques peuvent coexister avec un NgRx Store existant.

Puis allez plus loin

• Des tags sur deux dimensions : scope (qui parle à qui : scope:shop, scope:shared) × type (sens des dépendances : feature → ui / data-access → util). Les contraintes des deux s’appliquent avec un ET.
• Une seule API publique par feature/bibliothèque (un unique barrel à la frontière, jamais dans chaque dossier) ; les imports profonds et les imports statiques de bibliothèques lazy sont des violations.
• La granularité est un compromis : de petites bibliothèques par domaine et par type donnent des graphes nx affected étroits et des hits de cache ; une seule énorme bibliothèque shared fait que chaque PR affecte tout le dépôt.
• Ne déplacez vers shared que ce qui est générique, stable et déjà utilisé dans plusieurs features (« règle de trois ») ; les composants métier utilisés ailleurs restent dans leur feature propriétaire et sont exportés via son API publique.

'@nx/enforce-module-boundaries': ['error', {
  depConstraints: [
    // scope: who may talk to whom
    { sourceTag: 'scope:shop', onlyDependOnLibsWithTags: ['scope:shop', 'scope:shared'] },
    { sourceTag: 'scope:shared', onlyDependOnLibsWithTags: ['scope:shared'] },
    // type: which way dependencies flow
    { sourceTag: 'type:feature', onlyDependOnLibsWithTags: ['type:feature', 'type:ui', 'type:data-access', 'type:util'] },
    { sourceTag: 'type:ui', onlyDependOnLibsWithTags: ['type:ui', 'type:util'] },
    { sourceTag: 'type:util', onlyDependOnLibsWithTags: ['type:util'] },
    // ui never reaches data-access, not even transitively
    { sourceTag: 'type:ui', notDependOnLibsWithTags: ['type:data-access'] },
  ],
}],

Puis allez plus loin

• Classe abstraite plutôt qu’interface : une interface disparaît à la compilation, il faudrait donc un InjectionToken séparé ; la classe abstraite est à la fois le type et le token.
• Les erreurs font partie du contrat : l’adapter traduit les timeouts/503 en erreur de domaine, de sorte qu’aucun composant ne voit jamais HttpErrorResponse.
• Le bénéfice se voit dans les tests : règles de domaine en fonctions pures, cas d’usage avec un adapter en mémoire, et une suite de tests de contrat exécutée sur chaque adapter.
• Variante pragmatique : un domaine pur pour les règles qui comptent, un port seulement là où il y a (ou aura) plusieurs implémentations, le reste dans la structure habituelle data-access/ui — et faire respecter les couches avec le lint.

// application/task-repository.ts — the PORT (type + DI token)
export abstract class TaskRepository {
  abstract list(): Promise<readonly Task[]>;
  abstract save(task: Task): Promise<void>;
}

// infrastructure/http-task-repository.ts — the ADAPTER (HttpClient + DTO mapping)
@Injectable()
export class HttpTaskRepository extends TaskRepository { /* … */ }

// app.config.ts — the COMPOSITION ROOT
providers: [{ provide: TaskRepository, useClass: HttpTaskRepository }]

Puis allez plus loin

• Raisons valables : de nombreuses équipes avec des cadences différentes, de très grandes organisations, une migration strangler-fig depuis une application legacy, des produits distincts sous une même expérience.
• Angular doit être un singleton avec strictVersion, idéalement exactement la même version partout : deux runtimes, c’est des composants qui ne peuvent pas entrer dans l’arbre du shell et des services en double instance. Un remote sur une autre version majeure est isolé en Web Component ou en iframe.
• Traitez les exposes de chaque remote comme une API publique semver ; communiquez via l’URL, puis des événements typés, puis quelques services singleton partagés — jamais un store global partagé (c’est un monolithe distribué).
• Prévoyez les coûts dès le premier jour : un timeout et un fallback par remote, un manifest par environnement, le nom et la version du remote dans chaque erreur journalisée, des tests e2e sur la combinaison de production.

Puis allez plus loin

• Les attributs sont toujours des chaînes : les inputs numériques/booléens ont besoin de numberAttribute / booleanAttribute, et les objets/tableaux ne passent que par les propriétés.
• Les événements ne remontent pas (bubble) et ne sont pas composed : écoutez sur l’élément lui-même. Utilisez des noms d’output spécifiques (ratingChange, pas change).
• Utilisez ViewEncapsulation.ShadowDom pour que le CSS de la page hôte n’y fuite pas ; thématisez via des variables CSS et ::part().
• Regroupez les widgets d’une équipe en un seul bundle (un seul createApplication(), plusieurs appels define()), utilisez une balise différente du sélecteur du composant, et ne réutilisez pas un élément détruit — créez-en un nouveau.

Puis allez plus loin

• Le prerender avec paramètres nécessite getPrerenderParams ; PrerenderFallback.Server (le défaut) permet de prérendre les N premiers produits et de rendre le reste à la demande. Chaque URL est un rendu complet au moment du build.
• Le mode Server implique un processus Node : le TTFB est au moins celui de l’API la plus lente appelée pendant le rendu, du CPU par requête, et un état au niveau des modules partagé entre utilisateurs.
• Les bons codes de statut comptent pour le SEO : définissez le 404 via RESPONSE_INIT au lieu d’un soft 404 ; le cache se règle par route — public, s-maxage uniquement pour un contenu identique, private, no-store pour du HTML personnel.
• En v22, configurez allowedHosts (ou NG_ALLOWED_HOSTS) : un hôte inconnu reçoit un 400 en protection contre le SSRF. Si personne ne peut exploiter un serveur Node, utilisez le Prerender avec outputMode: 'static'.

Puis allez plus loin

• Contrairement à un @defer ordinaire, le contenu final est déjà à l’écran, donc vous pouvez différer au-dessus de la ligne de flottaison sans décalage de mise en page.
• hydrate never est réservé au contenu vraiment statique : il n’est pas annoté, donc rien n’est rejoué. Gardez le @placeholder : les déclencheurs hydrate sont ignorés lors d’une navigation côté client.
• withIncrementalHydration() est déprécié et withEventReplay() est redondant avec le défaut ; pour s’en désengager, on utilise withNoIncrementalHydration().
• N’enveloppez pas des composants de quelques Ko : le chunk et la requête supplémentaires coûtent plus qu’ils n’économisent. Utilisez des états CSS (:active, :focus-visible) pour que les utilisateurs voient que le clic a été pris en compte.

<app-product-header [product]="product()" />  <!-- hydrated at bootstrap -->

@defer (hydrate on interaction) {
  <app-gallery [images]="product().images" />  <!-- JS only at the first click -->
} @placeholder {
  <div class="gallery-skeleton"></div>         <!-- shown on client-side navigation -->
}

@defer (hydrate on viewport) {
  <app-reviews [productId]="id()" />           <!-- below the fold -->
} @placeholder {
  <div class="reviews-skeleton"></div>
}

@defer (hydrate never) { <app-footer /> }      <!-- static HTML forever -->

Puis allez plus loin

• @if (isPlatformBrowser(…)) dans un template ne lève pas d’erreur, mais Angular jette le DOM serveur de ce bloc et le reconstruit — un décalage de mise en page. Préférez @defer ou afterNextRender.
• Causes de mismatch : manipulation directe du DOM (innerHTML, appendChild), HTML invalide (<div> dans <p>), scripts tiers, un CDN qui supprime les commentaires (NG0507), et des valeurs comme Date.now() qui diffèrent entre plateformes.
• Les serveurs zoneless ne voient pas votre asynchrone maison (fetch, SDK, timers) : utilisez resource() ou PendingTasks, sinon le HTML part vide et le navigateur redemande les données.
• Fuites d’état : les variables au niveau des modules et les objets useValue sont partagés par tous les utilisateurs du processus Node ; utilisez des services ou useFactory.
• En équipe : un build SSR en CI, une checklist de relecture, et ngSkipHydration autorisé uniquement comme correctif documenté et temporaire.

Puis allez plus loin

• Chargement : routes lazy, @defer pour le contenu lourd sous la ligne de flottaison (jamais l’élément LCP), injectAsync() pour les services lourds et rarement utilisés, NgOptimizedImage avec priority sur l’image LCP, imports ciblés vérifiés avec source-map-explorer.
• Rendu : OnPush + signaux, track sur un identifiant stable, dérivations dans computed() plutôt que des méthodes de template ; pour des dizaines de milliers de lignes, le virtual scroll du CDK ou la pagination — OnPush réduit la fréquence, pas la quantité que vous rendez.
• Thread principal : les calculs continus de plus de ~50 ms (parsing, gros filtres) vont dans un Web Worker ; transférez des ArrayBuffer au lieu de copier d’énormes données.
• Contrôle des régressions : des budgets dans angular.json qui font échouer le build, une vérification de performance des pages clés à chaque release, et un responsable des chiffres.

Puis allez plus loin

• bypassSecurityTrust* n’est légitime que pour du contenu que vous construisez et contrôlez (une URL d’embed issue d’un identifiant validé). Une pipe générique « safeHtml » est un XSS réutilisable ; cherchez ces appels à chaque relecture.
• CSP : Angular a besoin d’un nonce pour ses styles inline — ngCspNonce sur l’élément racine ou le token CSP_NONCE ; security.autoCsp calcule les hashes au build mais ne couvre que les scripts et ne fonctionne pas avec le SSR.
• Déployez la CSP d’abord avec Content-Security-Policy-Report-Only, sinon les chunks lazy ou les styles inline cassent en production.
• CSRF avec cookies de session : HttpClient envoie le cookie XSRF-TOKEN sous la forme X-XSRF-TOKEN sur les requêtes mutantes de même origine — mais le serveur doit le définir et le vérifier. Chaque vérification côté frontend est répétée côté serveur.

Puis allez plus loin

• Le « refresh à chaque 401 » naïf produit N refreshes ; avec la rotation des refresh tokens, ils s’invalident mutuellement et certains serveurs traitent la réutilisation comme une attaque et tuent la session.
• Marquez le login/refresh avec un HttpContextToken (SKIP_AUTH) pour que l’interceptor ne s’intercepte pas lui-même, n’attachez le jeton qu’aux URL de votre API, et si le jeton a déjà changé depuis l’envoi de la requête, réessayez simplement.
• Seul le 401 déclenche un refresh — le 403 signifie « non autorisé ». Un refresh qui échoue entraîne une déconnexion, le vidage des stores et des caches, et la propagation de la déconnexion aux autres onglets (BroadcastChannel).
• Au démarrage, un provideAppInitializer tente un refresh avant la première route. Avec un fournisseur OIDC externe, utilisez une bibliothèque certifiée plutôt que de réimplémenter PKCE et la rotation à la main.

private refreshInFlight: Observable<string> | null = null;

refresh(): Observable<string> {
  this.refreshInFlight ??= this.http
    .post<{ accessToken: string }>('/auth/refresh', null, {
      withCredentials: true,                            // HttpOnly cookie
      context: new HttpContext().set(SKIP_AUTH, true),  // not intercepted again
    })
    .pipe(
      map((r) => r.accessToken),
      tap((t) => this.token.set(t)),                    // access token: memory only
      finalize(() => (this.refreshInFlight = null)),
      shareReplay(1),                                   // every 401 waits for the same one
    );
  return this.refreshInFlight;
}

Puis allez plus loin

• provideBrowserGlobalErrorListeners() achemine window.onerror et les rejets non gérés vers ErrorHandler ; gardez le handler simple et sûr — s’il lève une erreur, vous perdez toutes les erreurs.
• @boundary n’intercepte que les erreurs de rendu, pas celles des gestionnaires d’événements ni du code asynchrone, et une erreur interceptée est quand même signalée à ErrorHandler.
• L’interceptor relance après traitement (throwError(() => err)) pour que les appelants puissent encore réagir ; un catchError(() => of([])) sans journalisation rend les bugs invisibles.
• UX et exploitation : centralisez et dédupliquez les toasts (pas cinq messages pour un problème), traduisez les erreurs techniques en erreurs de domaine au niveau de l’adapter, et joignez du contexte (route, version, remote) à chaque erreur journalisée.

Puis allez plus loin

• switchMap pour des écritures est dangereux : une sauvegarde annulée a pu atteindre le serveur ou non. Les écritures utilisent concatMap ou exhaustMap.
• catchError va dans la projection interne ; placé après switchMap, la première requête échouée termine tout le flux et la recherche meurt en silence.
• Un simple shareReplay(1) a refCount: false : sur une source infinie (websocket, interval), il ne se désabonne jamais. Utilisez { bufferSize: 1, refCount: true } — en sachant que le cache ne survit que si la source s’est terminée.
• RxJS fonctionne en push sans backpressure intégrée, donc vous choisissez une politique : abandonner (switchMap, exhaustMap, throttleTime, auditTime, debounceTime), regrouper (bufferTime) ou limiter la concurrence (mergeMap(fn, 3)). Une file concatMap non bornée sur une source rapide fait grossir la mémoire.

readonly results$ = this.query$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap((q) =>
    this.api.search(q).pipe(
      catchError((err) => {
        this.log.error(err);
        return of([]);        // inside: only this request fails, the stream lives on
      }),
    ),
  ),
  shareReplay({ bufferSize: 1, refCount: true }),
);

Puis allez plus loin

• Depuis la v21, le runner par défaut est Vitest (@angular/build:unit-test) ; Karma est déprécié, et les anciennes suites peuvent être migrées avec le schematic expérimental refactor-jasmine-vitest.
• Tests zoneless : await fixture.whenStable() au lieu de fakeAsync, fake timers de Vitest pour le debounce, TestBed.tick() pour vider les effects ; inputs sous forme de signaux via inputBinding.
• Avec ports & adapters, exécutez une suite de tests de contrat sur chaque adapter ; les harnesses du CDK rendent les tests de composants indépendants de la structure du DOM.
• En CI : nx affected plus le cache pour la vitesse, pas de cache pour les e2e non déterministes contre un vrai backend, et la couverture comme signal, pas comme objectif.

Puis allez plus loin

• Changer de langue avec l’i18n intégrée implique un rechargement, même avec loadTranslations() à l’exécution, car les textes des templates sont évalués à la création des composants.
• Les pluriels exigent l’ICU, pas n === 1 ? … : … : le roumain a one, few et other (« 20 de fișiere »). Ne concaténez jamais des phrases — l’ordre des mots diffère d’une langue à l’autre.
• Des ids personnalisés (@@cart.title) pour que les traductions survivent aux modifications de la source ; dates, nombres et devises via des pipes avec LOCALE_ID et registerLocaleData.
• Il s’adapte au SSR/prerender (une variante par locale, choisie par l’URL), et avec l’hydration vous ajoutez withI18nSupport(). Commencez dès le premier jour : ajouter l’i18n plus tard, c’est traquer chaque chaîne codée en dur.

Puis allez plus loin

• Choix de la couche : Aria pour un design system sur mesure, CDK pour les primitives de bas niveau (overlay, drag & drop, utilitaires a11y), Material quand on veut rapidement une UI toute faite.
• Stylez selon l’état ARIA que posent les directives ([aria-selected='true']), pour que l’état visuel et l’état accessible ne puissent pas diverger.
• Compromis ailleurs : le virtual scroll retire les lignes hors écran du DOM (Ctrl+F et les lecteurs d’écran ne les voient pas) ; préférez la pagination là où l’accessibilité complète compte.
• Processus : vérifications au clavier et au lecteur d’écran dans la definition of done, contrôles automatisés en CI, et revue a11y intégrée au contrat du design system.

Puis allez plus loin

• HTTP : fetch est le backend par défaut et withFetch() est déprécié ; la progression d’upload nécessite withXhr(), et reportProgress devient reportUploadProgress / reportDownloadProgress.
• Routeur et templates : paramsInheritanceStrategy: 'always' (les routes enfants héritent des paramètres et des données de tous les parents), ?. renvoie undefined comme en TypeScript, un compilateur plus strict (inputs liés deux fois, data-* ne lie plus d’inputs), CanMatchFn nécessite currentSnapshot.
• Plateforme et suppressions : TypeScript 6 et pas de Node 20 ; ComponentFactoryResolver, ComponentFactory et provideRoutes ont disparu ; pour le SSR, configurez allowedHosts et retirez withIncrementalHydration().
• Déploiement : une branche de mise à niveau maintenue au vert en CI, bibliothèques et Node/TS mis à jour d’abord, e2e sur les parcours critiques, puis un plan de suivi pour retirer Eager fonctionnalité par fonctionnalité au lieu de le traiter comme permanent.