Angular et les signaux de la discorde
Tags: french, angular, frontend
Published: 2023-04-21 09:36:25

Cela fait maintenant presque 7 ans depuis sa première version stable, qu'_Angular_ amène régulièrement des nouveautés au sein de sa communauté. Chaque évolution a su améliorer progressivement ses performances et la richesse fonctionnelle  tout en conservant une rétro compatibilité appréciée des entreprises. _Signals_ est la dernière nouveauté en date qui devrait arriver avec la version 16 du _framework_.

Utilisés au sein du _framework_ SolidJS les signaux permettent de suivre l'évolution des valeurs de l'application et transmettre les changements de son état. Ils sont bâtis autour du motif de conception _observateur_ et constituent la pierre angulaire de la réactivité dans ce contexte. L'idée de l'équipe d'_Angular_ est d'introduire ces primitives de _SolidJS_ au sein de leur _framework_, fournissant ainsi une alternative à RxJS pour la réalisation d'une application réactive. Mais pourquoi décider d'introduire un nouveau paradigme au sein d'un _framework_ déjà connu pour sa complexité ? Pour comprendre cette décision, il faut se pencher sur le fonctionnement actuel d'une application _Angular_ et plus particulièrement la détection des changements. 

Une application Angular est construite sous la forme d'un arbre de composants. Pour déterminer si le DOM doit être mis à jour, le composant racine procède à des comparaisons de ses données, applique des modifications sur le DOM si nécessaire et enfin propage ce traitement à ses enfants. La bibliothèque _Zone.js_ détecte les traitements asynchrones et déclenche le processus de détection des changements. Cette automatisation a cependant un coût assez élevé que l'équipe d'Angular souhaite réduire depuis quelque temps.

Les signaux offrent une solution plus efficace en proposant un mécanisme basé sur l'observation de l'état pour déclencher ces mises à jour sans avoir à parcourir l'ensemble de l'arbre des composants. S'il est vrai qu'étudier la mise en place d'une solution alternative à _Zone.js_ est bienvenu, on pourra s'étonner que l'équipe ne creuse pas davantage d'autres pistes autour d'un écosystème déjà en place. 

_RxJS_ est une bibliothèque présente depuis le début du framework et fait partie, comme pour _TypeScript_ des choix de conception de base. Il aurait été intéressant d'envisager également des pistes autour de cette bibliothèque afin de capitaliser et renforcer son intégration. RxJS n'est pas connu pour sa simplicité et demande un investissement important des développeurs pour être maîtrisée. Mais son usage s'avère très efficace dans le cadre de la programmation réactive et elle permet d'adresser des problématiques que les signaux ne proposent pas de couvrir. Les signaux sont plus simples à appréhender, une simplicité qui pourrait permettre de séduire des développeurs rebutés par la complexité de RxJS. Nous ouvrons ici la porte à une alternative, une autre façon de faire, une autre façon de concevoir.

C'est sur ce dernier point que nous pouvons observer la réorientation de la gouvernance du framework Angular. La version 15 a vu l'introduction des Stand Alone Component et d'une alternative aux modules. Une nouvelle façon de créer son application, de l'architecturer, une nouvelle façon de concevoir. L'approche est compréhensible, l'héritage est important et il devient complexe d’innover dans ce contexte. Proposer de nouvelles fonctionnalités tout en conservant l'historique permet d'introduire des changements radicaux sans couper la rétro compatibilité (cf. questions-réponses [sous RFC-1](https://github.com/angular/angular/discussions/49684)). C’est ainsi que nous verrons bientôt cohabiter des composants fonctionnant avec Zone.js et les nouveaux basés sur les signaux (signals based components).

Quel avenir alors pour ces approches alternatives ? Quel sera le support sur le long terme ? Il est probable que ce soit l'usage qui fasse loi ici comme pour beaucoup de choses. Avec le temps il ne sera pas intéressant de maintenir des fonctionnalités peu utilisées par la communauté, surtout si ces alternatives se multiplient encore. Ce qui fait que la communauté d’_Angular_ est restée aussi fidèle c’est en partie pour sa stabilité et sa cohérence. Le _framework_ est loin d'être parfait, mais cette stabilité est une des raisons pour lesquelles les entreprises lui ont fait confiance si longtemps. Chercher de nouvelles pistes d'améliorations et tenter de rendre le _framework_ plus accessible sont des efforts louables, cependant il ne faudrait pas que cela soit à l'origine d'une rupture avec les usagers historiques. J’utilise _Angular_ depuis 2016 et j’en ai toujours été très satisfait. Pour bénéficier des signaux dans les applications existantes il me faudra envisager de réécrire une partie significative du code. A l’occasion d’un tel changement, si la stabilité du _framework_ n’est plus au rendez-vous, je pourrais préférer une des nombreuses alternatives.