Angular Signals

Le gros morceau de cette version : les Signals. Je pense que vous n'êtes pas passé à côté, on entend parler que de ça ces derniers mois et ce coup-ci c'est en version finale qu'on voit les Signals débarquer !

En résumé les Signals c'est une nouvelle API proposée par Angular (en s'inspirant de ce qui est fait ailleurs) pour proposer un mécanisme de réactivité fine permettant des re-rendus très fin de l'affichage et simplifiant la syntaxe pour pas mal de cas. L'ajout des Signals va très fortement changer la manière dont on code une application Angular en cassant un peu la dépendance à RxJS (même si RxJS va rester très présent mais peut-être moins visible pour pas mal de cas), et cassant très fortement le besoin de ZoneJS 🎉.

Comme tout le monde je ne vais pas déroger à la règle de vous montrer la syntaxe des Signals en copiant directement l'article officiel :

@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);
  }
}

Il faut bien comprendre une chose : ça ne casse pas le fonctionnement actuel de vos applications, donc ne vous inquiétez pas, vous n'avez pas besoin de ré-écrire vos applications à base de Signals, mais c'est potentiellement le moment de vous poser la question de retoucher les morceaux de code que vous savez manquer un peu de performance pour gratter un peu sans gros efforts 😉

DestroyRef & takeUntilDestroyed

Cette version introduit la notion de DestroyRef qui permet de s'abonner au destroy d'un composant sans passer par la méthode onDestroy(). C'est utile dans pas mal de cas, en particulier si on veut extraire une logique qu'on répète un peu partout, au hasard se désabonner des flux RxJS quand le composant est détruit ! Ça tombe bien parce que l'équipe Angular propose juste un opérateur qui fait ça en exploitant la DestroyRef du composant depuis lequel on appelle l'opérateur, ce qui permet d'écrire des choses du genre :

data$ = this.mySerivce.getData().pipe(takeUntilDestroyed());

SSR et Hydratation

Si vous n'avez jamais entendu parler de SSR (Server-Side Rendering) avec Angular c'est que vous êtes passé à côté d'Angular Universal qui était une librairie tierse permettant de faire du SSR avec Angular, je dis "était" car le projet devient un projet officiel et va bientôt être intégré comme partie intégrante du framework Angular.

Un gros travail a été effectué en parallèle de cette décision pour améliorer l'expérience utilisateur en ré-écrivant la manière dont est effectué le bootstrap d'une application Angular (sous le capôt uniquement, vous n'avez rien à faire) de sorte à éviter tout clignotement au moment de l'hydration (moment où on passe d'une page statique générée côté serveur à une SPA faisant un rendu côté client).

Plus généralement l'intégration de la partie SSR à Angular fait partie des hautes priorités de l'équipe Angular pour répondre aux attentes de la communauté et avoir une solution clé en main pour Angular (comme on a avec Next/ReMix chez React ou Nuxt chez Vue).

Renouveaux côté tests

Tout n'est pas complètement sec mais Karma est maintenant déprécié (j'étais de mon côté passé à côté de la nouvelle qui date d'avril 2023), il faut donc préparer l'avenir du testing avec Angular. Et pas mal de chose bougent à ce sujet.

Premier point qui fera plaisir à pas mal : le support de Jest comme runner de test est ouvert en expérimental. Comme ce n'est pas un code qui part en prod, je pense que vous pouvez tester sans trop vous poser de question, surtout qu'il s'agit d'une ligne à changer dans votre angular.json. Par contre il ne faut pas oublier que Jest n'exécute pas les tests dans un navigateur donc la représentativité des tests peut être discutable.

Karma ne sera prochainement plus utilisé pour exécuter les tests unitaires et sera remplacé par Web Test Runner pour conserver par défaut des tests unitaires exécutés dans un navigateur. Il sera couplé à Jasmine qui est déjà utilisé conjointement à Karma ce qui devrait permettre une migration avec très peu de modifications (modifications qui seront à priori prises en chargent par ng update comme d'habitude !).

Quelques petits sujets

Passage à TypeScript 5.0

Le passage à TypeScript 5.0 est optionnel c'est plus qu'Angular supporte cette version qui vient casser les décorateurs. Quand je dis "casser" ne vous inquiéter pas ça ne veut pas dire de gros changement mais un passage des décorateurs expérimentaux qu'on a l'habitude d'utiliser (et qui correspondent à une ancienne version de la spécification des décorateurs ECMAScript) à la version officielle des décorateurs. La casse se trouve dans le non support des décorateurs sur les paramètres (exemples : @Optional, @Inject, etc.) qui devront être remplacés par d'autres manière de faire (typiquement les @Inject pourront être remplacés par l'utilisation de la fonction inject()).

Comme ces décorateurs sont maintenant standards, ça permet aussi de réduire le travail de ngcc permettant de gagner un peu en performance de build.

esbuild en developer preview

On est plus proche que jamais de la sortie finale de cette feature très attendue : le support d'esbuild par le CLI. L'intérêt étant de gagner en performance au moment du build. Avec l'activation d'esbuild vient aussi l'utilisation de ViteJS pour ng serve ce qui va aussi améliorer l'expérience développeur.

À noter qu'on est toujours en preview essentiellement à cause de problème avec la gestion d'Angular i18n qui est problématique, donc si vous utilisez Angular i18n je pense que vous pouvez passer votre chemin pour l'instant, vous ne pourrez pas tester.

Conclusion

Comme j'entends pas mal dire ces derniers temps "2023 est l'année d'Angular", et cette verison 16 le prouve. Après une grosse version 15, on retrouve encore des gros ajouts, des grosses promesses pour l'avenir aussi avec des éléments qui arriveront dès la version 17 (en particulier côté SSR).

Sources :

• What's new in Angular 16
• Moving Angular CLI to Jest and Web Test Runner
• What’s next for Server Side Rendering in Angular
• Write better tests without Router mocks/stubs
• Angular v16 is here!
• La version 16 d'Angular est disponible
• What's new in Angular CLI 16.0?
• What's new in Angular 16?
• An introduction to Angular Signals
• Front-End Chronicles #16 No Signals (podcast en français)

Crédit photo : https://pixabay.com/photos/sweet-sixteen-balloons-sweet-sixteen-701710/