Programmation Réactive

Principe général

La programmation réactive permet de décrire un ensemble d’actions à réaliser, et souscrire au résultat, de sorte à libérer le thread en attendant que la requête ait commencé à émettre un résultat. Cela permet de produire du code non bloquant, mais au prix d’une perte en lisibilité (notamment lorsqu’on doit réaliser un traitement complexe sur la donnée récupérée). La programmation réactive peut être intéressante pour la lecture de donnée dans une page web, typiquement (donc RxJS, et seulement lorsqu’on attend une réponse du navigateur), avec relativement peu de traitement des données reçues, avant affichage dans le navigateur.

Observations

La programmation réactive consiste à faire en sorte que la liste de callback renvoi directement une souscription à laquelle notre client (l’appelant) souscrit, pour être informé, lorsque l’ensemble des calls ont aboutit. Si on fait foo(a).bar(b).baz(c), foo renvoi une souscription que bar récupère, de sorte que lorsque foo abouti, bar effectue son traitement, et de même pour baz. Tandis que la méthode qui a exécuté notre foo(a).bar(b).baz(c), attend elle-même que la souscription aboutisse pour en retourner le résultat. À un moment donné, il y aura toujours quelqu’un pour attendre le résultat. Après, on peut faire en sorte que la dernière souscription est envoyée au client via une websocket vers l’interface qui produira directement le rendu.

Piste de réflexion : si le backend supporte le GraphQL, on peut déjà filtrer la données à récupérer, les champs, etc. Du coup, le code réactif côté client se limitera à insérer la donnée dans un composant web adéquate. Cela implique d’ailleurs de prévoir un composant sur mesure qui prend en paramètre les données remontées par le call GraphQL. On arrive à un truc du genre : myConnection.query(‘graphql-code’).then(data => new MyComponent(jsonData));

À la récupération des données, on peut également mettre en place des solutions d’optimisation, comme le lazy loading, qui permet de récupérer certains détails à la demande (seulement au moment où le besoin s’en fait ressentir).

Comparaison avec asyn/await

Beaucoup de langages fournissent, en remplacement des callbacks, un fonctionnement de type async/await. L’idée du await est de dire au thread “quand tu arrives sur cette ligne de code, tu peux aller travailler avec un autre client, le temps que cette ligne renvoi une réponse, et t’inquiètes, on aura toujours quelqu’un pour prendre la main lorsque cette réponse sera arrivée”. Async/await est plus agréable et naturel à utiliser que la programmation réactive.