J'ai lu cette réponse , réduisant le passe-partout , regardé quelques exemples GitHub et même essayé un peu de redux (todo apps).
Si je comprends bien, les motivations officielles de doc redux fournissent des avantages par rapport aux architectures MVC traditionnelles. MAIS cela ne répond pas à la question:
Pourquoi devriez-vous utiliser Redux sur Facebook Flux?
Est-ce seulement une question de styles de programmation: fonctionnel vs non fonctionnel? Ou la question est dans les capacités / outils de développement qui découlent de l'approche redux? Peut-être une mise à l'échelle? Ou des tests?
Ai-je raison de dire que le redux est un flux pour les personnes issues de langages fonctionnels?
Pour répondre à cette question, vous pouvez comparer la complexité de la mise en œuvre des points de motivation de redux sur flux vs redux.
Voici les points de motivation des motivations officielles de redux doc :
- Gérer les mises à jour optimistes ( si je comprends bien, cela ne dépend guère du 5ème point. Est-il difficile de l'implémenter dans le flux facebook? )
- Rendu sur le serveur (le flux facebook peut également le faire. Des avantages par rapport au redux? )
- Récupération des données avant d'effectuer des transitions d'itinéraire ( Pourquoi cela ne peut-il pas être réalisé dans le flux Facebook? Quels sont les avantages? )
- Rechargement à chaud ( c'est possible avec React Hot Reload . Pourquoi avons-nous besoin de redux? )
- Fonctionnalité Annuler / Rétablir
- D'autres points? Comme un état persistant ...
Réponses:
Auteur Redux ici!
Redux n'est pas si différent de Flux. Dans l'ensemble, il a la même architecture, mais Redux est capable de réduire certains coins de complexité en utilisant une composition fonctionnelle où Flux utilise l'enregistrement de rappel.
Il n'y a pas de différence fondamentale dans Redux, mais je trouve que cela rend certaines abstractions plus faciles, ou du moins possibles à implémenter, qui seraient difficiles ou impossibles à implémenter dans Flux.
Composition du réducteur
Prenez, par exemple, la pagination. Mon exemple Flux + React Router gère la pagination, mais le code est horrible. L'une des raisons pour lesquelles c'est horrible est que Flux rend peu naturel la réutilisation des fonctionnalités dans les magasins. Si deux magasins doivent gérer la pagination en réponse à des actions différentes, ils doivent soit hériter d'un magasin de base commun (mauvais! Vous vous enfermez dans une conception particulière lorsque vous utilisez l'héritage), soit appeler une fonction définie en externe à partir du gestionnaire d'événements, qui devra en quelque sorte opérer sur l'état privé du magasin Flux. Le tout est désordonné (bien que certainement dans le domaine du possible).
En revanche, avec Redux la pagination est naturelle grâce à la composition réductrice. Il s'agit de réducteurs jusqu'en bas, vous pouvez donc écrire une usine de réducteurs qui génère des réducteurs de pagination , puis l' utiliser dans votre arborescence de réducteurs . La raison pour laquelle c'est si facile est que dans Flux, les magasins sont plats, mais dans Redux, les réducteurs peuvent être imbriqués via la composition fonctionnelle, tout comme les composants React peuvent être imbriqués.
Ce modèle permet également des fonctionnalités merveilleuses telles que l' annulation / la restauration sans code utilisateur . Pouvez-vous imaginer brancher Undo / Redo dans une application Flux avec deux lignes de code? À peine. Avec Redux, c'est encore une fois, grâce au schéma de composition du réducteur. Je dois souligner qu'il n'y a rien de nouveau à ce sujet - c'est le modèle mis au point et décrit en détail dans Elm Architecture qui a lui-même été influencé par Flux.
Rendu du serveur
Les gens ont bien rendu sur le serveur avec Flux, mais vu que nous avons 20 bibliothèques Flux chacune essayant de rendre le rendu du serveur "plus facile", peut-être que Flux a des bords rugueux sur le serveur. La vérité est que Facebook ne fait pas beaucoup de rendu de serveur, ils ne se sont donc pas beaucoup inquiétés à ce sujet et comptent sur l'écosystème pour le rendre plus facile.
Dans Flux traditionnel, les magasins sont des singletons. Cela signifie qu'il est difficile de séparer les données pour différentes demandes sur le serveur. Pas impossible, mais difficile. C'est pourquoi la plupart des bibliothèques Flux (ainsi que les nouveaux Flux Utils ) vous suggèrent désormais d'utiliser des classes au lieu de singletons, afin que vous puissiez instancier des magasins par demande.
Il y a encore les problèmes suivants que vous devez résoudre dans Flux (vous-même ou avec l'aide de votre bibliothèque Flux préférée telle que Flummox ou Alt ):
Certes, les frameworks Flux (pas Vanilla Flux) ont des solutions à ces problèmes, mais je les trouve trop compliqués. Par exemple, Flummox vous demande de l'implémenter
serialize()
etdeserialize()
dans vos magasins . Alt résout ce problème en fournissanttakeSnapshot()
une sérialisation automatique de votre état dans une arborescence JSON.Redux va plus loin: puisqu'il n'y a qu'un seul magasin (géré par de nombreux réducteurs), vous n'avez pas besoin d'API spéciale pour gérer la (ré) hydratation. Vous n'avez pas besoin de «vider» ou «hydrater» les magasins - il n'y a qu'un seul magasin, et vous pouvez lire son état actuel ou créer un nouveau magasin avec un nouvel état. Chaque demande obtient une instance de magasin distincte. En savoir plus sur le rendu du serveur avec Redux.
Encore une fois, il s'agit de quelque chose de possible à la fois dans Flux et Redux, mais les bibliothèques Flux résolvent ce problème en introduisant une tonne d'API et de conventions, et Redux n'a même pas à le résoudre car il n'a pas ce problème dans le première place grâce à la simplicité conceptuelle.
Expérience développeur
Je n'avais pas vraiment l'intention que Redux devienne une bibliothèque Flux populaire - je l'ai écrite pendant que je travaillais sur mon exposé ReactEurope sur le rechargement à chaud avec le voyage dans le temps . J'avais un objectif principal: permettre de changer le code réducteur à la volée ou même «changer le passé» en biffant les actions, et voir l'état se recalculer.
Je n'ai vu aucune bibliothèque Flux capable de le faire. React Hot Loader ne vous permet pas non plus de le faire - en fait, il casse si vous modifiez les magasins Flux parce qu'il ne sait pas quoi en faire.
Lorsque Redux doit recharger le code réducteur, il appelle
replaceReducer()
et l'application s'exécute avec le nouveau code. Dans Flux, les données et les fonctions sont enchevêtrées dans les magasins Flux, vous ne pouvez donc pas «simplement remplacer les fonctions». De plus, il faudrait en quelque sorte réenregistrer les nouvelles versions avec Dispatcher, ce que Redux n'a même pas.Écosystème
Redux possède un écosystème riche et à croissance rapide . En effet, il fournit quelques points d'extension tels que le middleware . Il a été conçu en tenant compte des cas d'utilisation tels que la journalisation , la prise en charge des promesses , des observables , du routage , des vérifications des développeurs d'immuabilité , la persistance , etc. Tout cela ne s'avérera pas utile, mais il est agréable d'avoir accès à un ensemble d'outils qui peuvent être facilement combinés pour fonctionner ensemble.
Simplicité
Redux conserve tous les avantages de Flux (enregistrement et relecture des actions, flux de données unidirectionnel, mutations dépendantes) et ajoute de nouveaux avantages (annulation facile à refaire, rechargement à chaud) sans introduire Dispatcher et l'enregistrement du magasin.
Il est important de rester simple, car il vous garde sain d'esprit pendant que vous implémentez des abstractions de niveau supérieur.
Contrairement à la plupart des bibliothèques Flux, la surface de l'API Redux est minuscule. Si vous supprimez les avertissements, commentaires et vérifications d'intégrité du développeur, c'est 99 lignes . Il n'y a pas de code asynchrone délicat à déboguer.
Vous pouvez le lire et comprendre tout Redux.
Voir aussi ma réponse sur les inconvénients de l'utilisation de Redux par rapport à Flux .
la source
${login}/${name}
). Merci beaucoup!À Quora, quelqu'un dit :
Aussi ce diagramme visuel que j'ai créé pour montrer une vue rapide des deux, probablement une réponse rapide pour les personnes qui ne veulent pas lire toute l'explication:
Mais si vous souhaitez toujours en savoir plus, lisez la suite.
Depuis les documents Redux :
Également à partir des documents Redux :
la source
Il vaut peut-être mieux commencer par lire cet article de Dan Abramov où il discute de diverses implémentations de Flux et de leurs compromis au moment où il écrivait redux: L'évolution des cadres de flux
Deuxièmement, cette page de motivations vers laquelle vous liez ne traite pas vraiment des motivations de Redux autant que des motivations derrière Flux (et React). Les trois principes sont plus spécifiques à Redux mais ne traitent toujours pas les différences de mise en œuvre de l'architecture Flux standard.
Fondamentalement, Flux possède plusieurs magasins qui calculent les changements d'état en réponse aux interactions UI / API avec les composants et diffusent ces changements en tant qu'événements auxquels les composants peuvent s'abonner. Dans Redux, il n'y a qu'un seul magasin auquel chaque composant est abonné. OMI, il semble au moins que Redux simplifie et unifie davantage le flux de données en unifiant (ou en réduisant, comme dirait Redux) le flux de données vers les composants - tandis que Flux se concentre sur l'unification de l'autre côté du flux de données - voir modèle.
la source
Je suis un des premiers à adopter et à implémenter une application d'une seule page de taille moyenne à l'aide de la bibliothèque Facebook Flux.
Comme je suis un peu en retard dans la conversation, je vais juste souligner que malgré mes meilleurs espoirs, Facebook semble considérer leur mise en œuvre de Flux comme une preuve de concept et n'a jamais reçu l'attention qu'elle mérite.
Je vous encourage à jouer avec, car il expose davantage le fonctionnement interne de l'architecture Flux qui est assez pédagogique, mais en même temps, il ne fournit pas beaucoup des avantages que les bibliothèques comme Redux fournissent (qui ne sont pas cela est important pour les petits projets, mais il devient très précieux pour les plus grands).
Nous avons décidé que nous allons passer à Redux et je vous suggère de faire de même;)
la source
Voici l'explication simple de Redux sur Flux. Redux n'a pas de répartiteur, il s'appuie sur des fonctions pures appelées réducteurs. Il n'a pas besoin d'un répartiteur. Chaque action est gérée par un ou plusieurs réducteurs pour mettre à jour le magasin unique. Étant donné que les données sont immuables, les réducteurs retournent un nouvel état mis à jour qui met à jour le magasin
Pour plus d'informations Flux vs Redux
la source
J'ai travaillé assez longtemps avec Flux et maintenant assez longtemps avec Redux. Comme Dan l'a souligné, les deux architectures ne sont pas si différentes. Le fait est que Redux rend les choses plus simples et plus propres. Il vous apprend quelques choses en plus de Flux. Comme par exemple, Flux est un exemple parfait de flux de données unidirectionnel. Séparation des préoccupations lorsque nous avons des données, leurs manipulations et la couche de vue séparés. Dans Redux, nous avons les mêmes choses, mais nous apprenons également l'immuabilité et les fonctions pures.
la source
D'un nouvel adoptant react / redux migrant depuis (quelques années) d'ExtJS mi-2018:
Après avoir reculé dans la courbe d'apprentissage redux, j'avais la même question et je pensais que le flux pur serait plus simple comme OP.
J'ai rapidement vu les avantages du redux sur le flux, comme indiqué dans les réponses ci-dessus, et je l'ai intégré dans ma première application.
Tout en reprenant le contrôle de la plaque de la chaudière, j'ai essayé quelques-unes des autres bibliothèques de gestion d'état, la meilleure que j'ai trouvée était la revanche .
C'était beaucoup plus intuitif que vanilla redux, cela coupe 90% du passe-partout et 75% du temps que je passais sur redux (quelque chose que je pense qu'une bibliothèque devrait faire), j'ai pu obtenir quelques applications d'entreprise aller tout de suite.
Il fonctionne également avec le même outillage redux. Ceci est un bon article qui couvre certains des avantages.
Donc, pour tous ceux qui sont arrivés à ce poste SO à la recherche de "redux plus simple", je recommande de l'essayer comme une alternative simple à redux avec tous les avantages et 1/4 du passe-partout.
la source
Selon cet article: https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075
Vous feriez mieux d'utiliser MobX pour gérer les données de votre application pour obtenir de meilleures performances, pas Redux.
la source