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). 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.