Il n'est surprenant pour personne que JavaScript est partout.
Ici à Imaginary Cloud, la plupart des projets auxquels nous participons l'utilisent comme langue principale. Mon dernier projet était une application assez volumineuse impliquant les coupables habituels du Écosystème JavaScript. Nous avons utilisé une interface React et une pile principale Node.js.
Lorsque nous avons dû définir un stack pour ce projet, en raison de sa nature impliquant beaucoup de présentation visuelle et de modélisation 3D, React s'est présenté comme un choix évident en ce qui concerne la technologie frontale.
Malheureusement, à cette époque, aucune stratégie claire pour la gestion de l'État n'avait été définie. Au fur et à mesure que le projet évoluait, cela a commencé à devenir un problème. L'équipe a donc décidé de migrer toute la logique liée à la gestion des états vers une classe qui se présentait comme un Singleton. Cela aiderait à gérer tout le stockage et les événements liés à l'état. Cette solution était bonne à court terme, mais elle finirait par devenir plus utile pour lui et un plan a été mis en place pour trouver une meilleure alternative. Il est venu sous la forme de Redux, aidé par l'introduction de Boîte à outils Redux, précédemment connu sous le nom de Redux Starter Kit.
Redux est un conteneur d'états pour les applications JavaScript qui vous permet de contourner le flux de données unidirectionnel naturel de React. Cela est possible car il dispose d'une source de vérité que vous pouvez consulter dans l'ensemble de votre application, sans avoir à explorer l'état inférieur pour vous appuyer sur d'autres composants. Cependant, il vous permet également de modifier à l'aide d'actions prédéfinies, tout en conservant un historique de ces actions et mutations, qui peut être consulté lors des tests.
Lorsque Facebook a présenté React au monde entier, ils avaient déjà compris à quel point les accessoires pouvaient devenir un obstacle majeur lorsqu'ils atteignaient un certain niveau de complexité. Pour remédier à ce problème, ils ont introduit un concept aux côtés de React appelé Flux, qui décrit comment un magasin doit fonctionner en conjonction avec React. Redux, comme nous le savons aujourd'hui, provient d'une simple preuve de concept piratée par Dan Abramov, alors qu'il modifiait les principes de Flux pour React Europe.
Redux est utilisé dans des applications à grande échelle où une interaction avec un composant peut propager les modifications à l'ensemble de la page. Pour faciliter ce type de communication entre les composants, au lieu d'avoir à créer des callbacks au niveau supérieur de l'application, vous pouvez simplement consulter la boutique. Dans mon projet actuel, Redux est logique, car l'application avait atteint un point tel que les accessoires liés à son état étaient transmis à travers plusieurs couches de composants, ce qui rendait le code difficile à lire et encore plus difficile à déboguer.
Redux avait l'air d'une aubaine lorsque nous avons commencé à migrer l'ancien code vers cette nouvelle fonctionnalité. Cela a fait le code look slicker, c'était extrêmement intuitif pour comprendre et a considérablement réduit le nombre d'accessoires flottant autour de l'application. Mais ce n'était pas parfait. La nature même des réducteurs pose problème lorsqu'il s'agit de récupérer des informations qu'ils contiennent, et c'est un problème que la communauté Redux aborde depuis très longtemps.
Les réducteurs, en théorie, sont de pures fonctions, selon la documentation lui-même.
Avec les mêmes arguments, il doit calculer l'état suivant et le renvoyer. Pas de surprises. Pas d'effets secondaires. Aucun appel d'API. Aucune mutation. C'est juste un calcul.
Alors, où devriez-vous appliquer des appels asynchrones dans Redux?
Les actions devraient être la réponse immédiate, mais l'implémentation de base des actions n'est rien de plus qu'un simple objet JavaScript que vous utilisez pour transmettre des informations à votre boutique. Pour cette raison, la communauté a mis au point plusieurs intergiciels qui intègrent toute la logique dans des fonctions, qui imitent le comportement naturel du magasin.
Comme pour tout ce qui concerne la programmation, il n'existe pas de solution universelle. Vous devez donc absolument rechercher quel intergiciel correspond le mieux à votre problème. La première solution proposée par la documentation est Redux Thunk. Ce middleware vous permet de créer des actions qui ne se limitent pas à de simples objets. Ces nouvelles actions peuvent envoyer d'autres actions, d'autres Thunks et aussi effectuer des opérations asynchrones à l'intérieur d'eux. Mais récemment, d'autres intergiciels ont commencé à gagner du terrain, comme Saga Redux et Redux-Observable ont des cas d'utilisation différents, mais ils partagent tous une chose, à savoir un référentiel très actif et une communauté florissante derrière eux.
Parmi toutes les solutions populaires à ce problème, Redux Thunk est la plus facile à comprendre. Il est également assez accessible en termes techniques et, pour le moment, c'est la manière suggérée pour aborder cette situation selon la documentation Redux.
Nous commençons ici :
Cela vous permettra d'obtenir une nouvelle application utilisant React avec tous les modules Redux dont nous avions besoin pour réaliser ce court tutoriel. Nous travaillerons également avec WoofBot Service d'API.
La première chose à faire est de configurer une tranche pour chien, dans laquelle vous conserverez toutes les informations relatives à la réponse de l'API de votre chien.
Nous avons nos actions :
et sélecteurs :
Comment implémenteriez-vous normalement cela dans les deux sens avec l'API et le magasin ? Je mettrais tout cela dans un Crochet UseEffect, similaire à celui-ci :
Que faisons-nous ici ?
Sinon, nous pouvons recevoir une erreur de l'API qui arrêtera le flux à l'étape 4 et définira l'état de chargement sur Erreur.
Cela fonctionne, et ce n'est pas grave. Mais elle présente également plusieurs inconvénients. Principalement, cela met trop de logique dans le composant. Il n'est pas réutilisable, et si vous souhaitez accéder à ces informations ailleurs, vous devez toujours vous assurer que ce composant est chargé en premier.
Maintenant avec Thunks:
La logique des composants ressemble à ceci :
Nous devons créer une nouvelle action FetchBreeds qui ressemble beaucoup à la logique que nous avions précédemment utilisée dans le composant :
Ce simple changement d'emplacement dans le code corrige la plupart des problèmes que nous avions précédemment. Nous avons extrait le code du composant et avons rendu cette logique spécifique réutilisable dans l'ensemble de la base de code. Ces informations ne sont plus liées au montage du composant, vous pouvez donc maintenant émettre une nouvelle action FetchBreeds et les données seront chargées.
Cela nous permet également d'enchaîner Thunks au cas où nous aurions besoin d'une logique plus complexe dans nos actions. Nous pouvons également accéder directement à l'état, au lieu d'avoir besoin de sélecteurs. Cependant, vous souhaiterez toujours utiliser des sélecteurs pour vous assurer que les modifications apportées à Redux n'affectent pas vos Thunks.
Cela dépend de la situation. De la même manière, vous ne pouvez pas utiliser une cuillère pour tout, la solution doit être choisie en fonction du problème et non l'inverse.
Dans les problèmes les plus récents auxquels j'ai été confronté, Thunks a largement suffi à satisfaire tous mes cas extrêmes. Mais peut-être que dans votre cas, vous aurez besoin d'une solution plus spécifique.
Faites vos recherches, tenez-vous au courant et vous aurez toujours le meilleur outil à vos côtés.
Vous avez trouvé cet article utile ? Ceux-ci vous plairont peut-être aussi !
Votre développeur web de tous les jours qui aime se cacher dans le backend. Javascript et Ruby sont mes préférés. Je me débrouille toujours avec Docker et mes builds se cassent assez souvent.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
