Vous êtes sur votre site préféré, vous appuyez sur un bouton : un spinner de chargement apparaît, signe que votre demande est en cours de traitement. En fait, en appuyant sur ce bouton, vous avez provoqué un petit changement dans le modèle de données de l’application, auquel l’interface a réagi pour vous tenir informé de ce qui se passe.
De nos jours, la réactivité est au cœur du développement frontend. Les frameworks modernes reposent presque tous dessus, mais pas de la même façon : il existe une multitude de manières de l’implémenter.
Dans cet article, démystifions le concept de réactivité, en quoi elle est indispensable et comment elle se traduit dans différents frameworks.
Sans réactivité, ça donne quoi ?
Sans réactivité, le développeur est obligé de mettre à jour « manuellement » l’interface, en retrouvant lui-même les éléments impactés par le changement et en leur affectant la nouvelle valeur.
let count = 0;
function increment() {
count++;
document.querySelector("#counter").innerText = count;
}
En plus d’être fastidieux, cela comporte plusieurs risques :
- S’il y a beaucoup d’éléments impactés, la quantité de code à produire peut vite grossir
- La maintenance devient complexe : tout changement à effectuer doit être identifié et répercuté dans tous les composants impactés
- Le moindre oubli peut se traduire par une incohérence entre l’état réel et ce que voit l’utilisateur
Ce serait bien si l’interface pouvait réagir toute seule aux changements… C’est justement pour ça que la réactivité existe ! Elle fait en sorte que l’UI soit une projection de l’état de l’application.
Comment définit-on la réactivité ?
La réactivité en frontend est un mécanisme qui permet de mettre à jour automatiquement l’UI lorsque des données sont modifiées, le tout sans avoir à manipuler directement le DOM.
Si l’on reprend l’exemple du compteur ci-dessus, lorsque la valeur de count change, tous les éléments de la vue qui en dépendent sont mis à jour.
La vue n’est alors qu’une conséquence, une projection de l’état de l’application, qui devient dès lors source de vérité.
Les avantages sont multiples :
- Maintenance facilitée
- Moins de code impératif
- Cohérence entre les données et l’interface
- Code plus prédictif et testable
D’un point de vue développeur, ça retire la charge de penser aux manipulations du DOM, en se concentrant uniquement sur les données !
Comment ça marche ?
Il existe une myriade de façons d’implémenter un système réactif. Chaque framework possède son approche (voire même plusieurs ! ) : détection des changements, propagation, mise à jour de l’UI…
Voici quelques approches parmi les plus courantes.
Data binding (liaison de données)
Le data binding établit un lien entre les données et la vue. Il peut être :
- unidirectionnel (One-way data binding) : les données alimentent la vue. Néanmoins, les modifications dans l’interface ne mettent pas forcément les données du modèle à jour automatiquement
- Bidirectionnel (Two-way data binding) : Les modifications de la vue mettent à jour les données et inversement
React implémente un flux de données unidirectionnel : la donnée est répercutée dans la vue, mais les interactions passent par des callbacks pour remonter l’information dans l’autre sens
Angular, pour sa part, permet le two-way data binding (via [(ngModel)])
Avantage :
- La synchronisation entre l’état et l’UI est simplifiée
Inconvénients :
- Le One-way data binding peut demander plus de code pour remonter les nouvelles informations
- Le Two-way data binding peut être plus difficile à maintenir : il est moins aisé d’appréhender le flux de données, surtout pour des applications complexes
Virtual DOM (DOM virtuel)
Avec le Virtual DOM, le framework garde en mémoire une représentation de l’interface. Lorsqu’un changement doit être effectué :
- Le framework met à jour le Virtual DOM
- Il compare les différences entre le virtual DOM et le DOM réel : c’est la phase de diffing.
- Il applique uniquement les changements nécessaires au vrai DOM.
Avantage :
- Les modifications au DOM étant coûteuses, cette méthode permet de gagner en performance.
Inconvénients :
- Cette méthode est plus gourmande en mémoire, puisqu’il faut stocker toute la représentation du DOM
- L’étape de diffing est une étape supplémentaire par rapport à d’autres méthodes plus directes. Selon son implémentation, les performances peuvent varier.
- Lorsqu’un changement survient, c’est tout un composant qui peut être recalculé, même pour une seule valeur.
React et Vue utilisent tous les deux un Virtual DOM. Néanmoins, leur algorithme de diffing diffère, ce qui peut offrir des avantages selon les cas d’usage.
Les observables
Les observables sont des flux de données auxquels des composants s’abonnent. Lorsqu’un changement s’opère, ils sont notifiés et sont mis à jour.
On le trouve notamment dans Angular via la bibliothèque RxJS. À noter que RxJS ne met pas à jour l’UI automatiquement : il gère les flux de données, et c’est au développeur de gérer la mise à jour de la vue.
Avantage :
- Les observables permettent de gérer des événements complexes ainsi que les données asynchrones
Inconvénient :
- Ce paradigme est moins facile à appréhender que d’autres
Les signaux
Les signaux (signals en anglais) sont des valeurs observables, généralement synchrones. Lorsqu’un signal change, les composants qui s’en servent sont notifiés. Leur puissance réside dans le fait que les changements sont très ciblés, ce qui les rend hautement performants.
Avantages :
- Les signaux offrent d’excellentes performances, grâce à leur granularité des mises à jour
- L’API offre un usage simple
Inconvénient :
- Plus récents que la plupart des autres paradigmes, les ressources sont plus limitées
On les trouve dans SolidJS, qui les a implémentés dès 2018. D’autres frameworks ont emboîté le pas depuis : Angular, Preact, Svelte (avec les runes)… Leur adoption est grandissante au fil du temps, et il est possible que cela devienne un élément standard du frontend dans les années qui viennent.
Il existe d’ailleurs une proposition de les intégrer nativement à Javascript en discussion : https://github.com/tc39/proposal-signals
Conclusion
La réactivité est un élément incontournable du développement frontend. L’UI s’adapte à l’état de l’application automatiquement, ce qui permet au développeur de raisonner sur l’état de l’application et de faire abstraction du DOM.
Bien qu’il existe de multiples implémentations, l’objectif initial demeure de rendre l’expérience de développement plus fluide et d’améliorer la maintenabilité du code.
Une tendance se dégage avec le temps : avoir une meilleure granularité, minimiser les impacts des changements, avoir moins de rendus inutiles. En cela, les signaux (signals) pourraient bien devenir une référence à l’avenir.
Julien Tanguy
