Je travaille avec React depuis près de 3 ans, j'ai utilisé Redux et MobX, et j'ai maintenant une question. Pourquoi la grande majorité des développeurs front-end continuent de croire fermement que Redux + Redux Saga + Reselect + 100500 autres bibliothèques qui facilitent la vie est la meilleure solution à ce jour? Je donnerai 4 arguments en faveur de l'utilisation de MobX au lieu de Redux dans le prochain projet.
MobX vous permet d'écrire du code plus propre et plus propre
Sauvegardons 2 morceaux de code qui font la même chose. Voici à quoi ressemble un réducteur dans Redux:
Pour changer d'état, vous devez appeler une fonction appelée action dans la terminologie Editors:
Et dans la plupart des cas (pas toujours, mais ce sont les "meilleures pratiques" utilisées sur de nombreux projets), vous devrez écrire ce passe-partout:
Ensuite, il sera nécessaire d'initialiser le magasin (cela devra être fait une fois, mais quand même):
Et jetez notre mémoire initialisée plus loin dans l'application via le fournisseur (également une opération unique):
Vous pouvez maintenant effectuer certaines opérations avec des données dans vos composants:
Il s'avère que dans le cas de Redux, afin de changer les données dans votre stockage, vous devez appeler certaines fonctions qui créeront un nouvel objet d'état ... Personnellement, pour moi, cela ressemble à un non-sens complet. Jetons un coup d'œil à la même fonctionnalité effectuée par MobX. Notre côté:
Et puis vous pouvez l'utiliser dans le composant:
Oui, c'est vrai, au lieu de certaines fonctions qui modifient les objets, vous pouvez utiliser l'approche OOP classique, avec les classes, leurs propriétés et méthodes. N'ayez pas peur des décorateurs (@) à l'intérieur, ils ajoutent simplement les fonctionnalités nécessaires pour suivre les modifications des données. Soit dit en passant, une approche similaire, avec des classes, pour le stockage de données est utilisée dans Angularjs (écran tiré d'ici
angular.io/start/data ):
MobX vous permet d'écrire moins de code
Pour voir cela, regardez simplement les exemples ci-dessus. Et maintenant, au lieu d'écrire un passe-partout sans fin, vous pouvez enfin vous concentrer sur l'écriture de la logique métier de l'application, ce qui est une bonne nouvelle.
Troisièmement, l'optimisation des performances
Si vous regardez les exemples ci-dessus, vous pouvez voir que dans le cas de MobX, je n'ai pas utilisé un composant pur et ce n'est pas une erreur. Dans ce cas, vous n'avez tout simplement pas besoin d'utiliser d'optimisation, car votre composant ne sera restitué que lorsque les données que vous y utiliserez changent. Et oui, vous pouvez oublier Pure Components, shouldComponentUpdate et quoi d'autre utilisez-vous dans ces cas. Idéalement, chacun de vos composants qui ne sont pas HOC et utilisent des données du stockage doit être observable et vous oublierez à jamais les problèmes d'optimisation.
Quatrième - Moins de dépendances
Quiconque utilise Redux doit savoir par lui-même que de nombreuses «merveilleuses» bibliothèques l'accompagnent. Et c'est bien si c'est juste un thunk, ou peut-être que c'est le cas, les développeurs suivront le chemin de la
lumière des ténèbres et voudront utiliser Redux Saga, Reslect et un tas de bibliothèques étranges qui rendent votre code non seulement plus lent, mais aussi plus difficile à comprendre. Et pour terminer certaines fonctionnalités mineures ou trouver un bogue dans ce travail sera incroyablement difficile et long. MobX est la solution ultime == qui ne nécessite pas de bibliothèques supplémentaires, vous privera de tous ces charmes, donc avec elle la logique métier de votre application sera propre, comme une larme de bébé.
UPD Merci
MaZaAaLa cinquième raison - la possibilité d'abandonner setState
setState a un certain nombre d'inconvénients (une brève traduction de l'article
qui peut être lu dans l'original ici ):
1. Il est asynchrone.
Cela peut conduire à un comportement inattendu:
Sur l'écran ci-dessus, l'alerte aurait dû être de 2, mais comme setState est asynchrone, cela vient plus tard.
2. setState conduit à des rendus de composants inutiles:
a. Il est rendu même si la nouvelle valeur == l'ancienne valeur
b. Il y a des situations où le changement d'état n'entraîne aucun changement, par exemple, lorsque nous avons des conditions pour afficher l'état dans lequel. Sur la capture d'écran ci-dessous, un clic s'est produit sur le moteur de rendu, bien que les données ne devraient pas être rendues en raison de la condition de fasle:
c. Parfois, les données mises à jour par setState ne jouent aucun rôle dans le rendu DOM (par exemple, les minuteurs). Et tout de même, le composant est en cours de rendu.
3. setState ne convient pas à tous les cas.
Il existe des composants qui utilisent des hooks / méthodes de cycle de vie des composants et dans ce cas, non seulement un rendu supplémentaire se produira, mais ces événements (hooks) seront appelés à chaque fois en même temps, ce qui peut conduire à un comportement étrange.
L'utilisation de MobX vous protégera de ces lacunes, car vous pouvez abandonner complètement setState:
Si vous n'êtes pas d'accord avec quelque chose ou si je ne comprends pas quelque chose, veuillez donner les contre-arguments dans les commentaires. Lien vers le bac à sable à partir duquel les captures d'écran de MobX sont prises:
codesandbox.io/s/mobxreact-s7db5 , avec Redux:
codesandbox.io/s/oj7px08qy9