Voici une proposition qui décrit une première direction commune pour les signaux en JavaScript, similaire à l'effort Promises/A+ qui a précédé les Promesses standardisées par TC39 dans ES2015.Comme pour Promises/A+, cet effort se concentre sur l'alignement de l'écosystème JavaScript. Si cet alignement est réussi, alors une norme pourrait émerger, basée sur cette expérience. Plusieurs auteurs de frameworks collaborent ici sur un modèle commun qui pourrait soutenir leur noyau de réactivité. Le projet actuel est basé sur les contributions des auteurs/mainteneurs d'Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, et bien d'autres encore...
Contrairement à Promises/A+, cette proposition n'essaie pas de trouver une API de surface commune pour les développeurs, mais plutôt la sémantique précise du graphe de signaux sous-jacent. Cette proposition inclut une API entièrement concrète, mais elle n'est pas destinée à la plupart des développeurs d'applications. Au contraire, l'API de signal proposée est mieux adaptée aux cadres de travail à construire au-dessus, fournissant une interopérabilité par le biais d'un graphe de signal commun et d'un mécanisme de suivi automatique.
L'objectif de cette proposition est de réaliser des prototypes préliminaires significatifs, y compris l'intégration dans plusieurs frameworks, avant de dépasser l'étape 1. Cette proposition ne s'intéresse pas par la normalisation des signaux que s'ils peuvent être utilisés en pratique dans plusieurs cadres et s'ils offrent de réels avantages par rapport aux signaux fournis par les cadres. Un prototypage précoce significatif permettra d'obtenir ces informations.
Contexte : Pourquoi des signaux ?
Pour développer une interface utilisateur (UI) complexe, les développeurs d'applications JavaScript doivent stocker, calculer, invalider, synchroniser et transmettre l'état à la couche de visualisation de l'application de manière efficace. Les interfaces utilisateur ne se limitent généralement pas à la gestion de simples valeurs, mais impliquent souvent le rendu d'un état calculé qui dépend d'un arbre complexe d'autres valeurs ou d'un état qui est lui-même calculé. L'objectif des signaux est de fournir une infrastructure pour gérer l'état de ces applications afin que les développeurs puissent se concentrer sur la logique commerciale plutôt que sur ces détails répétitifs.
Les constructions de type signal se sont révélées utiles dans des contextes autres que l'interface utilisateur, en particulier dans les systèmes de construction afin d'éviter les reconstructions inutiles.
Les signaux sont utilisés dans la programmation réactive pour supprimer la nécessité de gérer les mises à jour dans les applications.
Exemple - Un compteur VanillaJS
Avec une variable, counter, vous voulez rendre dans le DOM si le compteur est pair ou impair. Chaque fois que counter change, vous voulez mettre à jour le DOM avec la dernière parité. Dans Vanilla JS, vous pourriez avoir quelque chose comme ceci :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 | let counter = 0;
const setCounter = (value) => {
counter = value;
render();
};
const isEven = () => (counter & 1) == 0;
const parity = () => isEven() ? "even" : "odd";
const render = () => element.innerText = parity();
// Simulate external updates to counter...
setInterval(() => setCounter(counter + 1), 1000); |
Cela pose un certain nombre de problèmes...
- La configuration du counter est bruyante et lourde.
- L'état du counter est étroitement lié au système de rendu.
- Si le counter change mais que la parity ne change pas (par exemple, le compteur passe de 2 à 4), le calcul de la parité et le rendu sont inutiles.
- Que se passe-t-il si une autre partie de l'interface utilisateur souhaite simplement effectuer un rendu lorsque le counter est mis à jour ?
- Que se passe-t-il si une autre partie de l'interface utilisateur dépend de isEven ou de la parity uniquement ?
Même dans ce scénario relativement simple, un certain nombre de problèmes se posent rapidement. On pourrait essayer de les contourner en introduisant la fonction pub/sub pour le counter. Cela permettrait à d'autres consommateurs du counter de s'abonner pour ajouter leurs propres réactions aux changements d'état.
Cependant, on est toujours confrontés aux problèmes suivants :
- La fonction de rendu, qui ne dépend que de la parity, doit au contraire "savoir" qu'elle doit s'abonner au counter.
- Il n'est pas possible de mettre à jour l'interface utilisateur en se basant uniquement sur isEven ou la parity, sans interagir directement avec le counter.
- On a augmenté le code passe-partout. Chaque fois que vous utilisez quelque chose, il ne s'agit pas simplement d'appeler une fonction ou de lire une variable, mais plutôt de s'abonner et de faire des mises à jour à cet endroit. La gestion du désabonnement est également particulièrement compliquée.
On pourrait résoudre quelques problèmes en ajoutant pub/sub non seulement à counter mais aussi à isEven et parity. On devrait alors abonner isEven à counter, parity à isEven et render à parity. Malheureusement, non seulement le code de base a explosé, mais on est coincé avec une tonne de comptabilité d'abonnements, et un désastre potentiel de fuites de mémoire si on ne nettoit pas tout de la bonne manière. On a donc résolu certains problèmes, mais on a créé une toute nouvelle catégorie de problèmes et beaucoup de code. Pour aggraver les choses, on doit suivre tout ce processus pour chaque élément d'état du système.
Présentation des signaux
Les abstractions de liaison de données dans les interfaces utilisateur pour le modèle et la vue sont depuis longtemps au cœur des cadres d'interface utilisateur dans de nombreux langages de programmation, malgré l'absence d'un tel mécanisme intégré à JS ou à la plateforme web. Au sein des frameworks et des...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par TotoParis
