Redux: Demande de discussion : "passe-partout" Redux, courbe d'apprentissage, abstraction et opiniâtreté

Quelques idées :

• paquet officiel redux-preset contenant redux, react-redux, redux-thunk déjà câblés ensemble
• dispatch(actionType, payload) pourrait réduire le besoin de créateurs d'action
• créateurs de réducteurs de style jumpstate intégrés, par exemple createReducer({[actionType]: (state, payload) => state}, initState)

La plupart des gens que je connais qui utilisent fortement redux, finissent par s'éloigner de redux-thunk car ils trouvent qu'il ne s'adapte pas très bien, et finissent par conduire à des créateurs d'action qui commencent à en faire beaucoup trop, et utilisent plutôt autre chose pour gérer le côté -effets comme redux-observable ou redux-saga.

Je peux comprendre l'attrait qu'il présente, en particulier lorsque je commence à utiliser le redux - mais je ne suis pas sûr que le regrouper dans le cadre d'un "paquet passe-partout des meilleures pratiques" serait la meilleure idée.

Donc, cette partie est la plus critique pour moi (ce ne seront pas tant des idées pour résoudre le problème, mais plutôt des contraintes qui sont, au moins pour moi, importantes) :

Redux n'est pas destiné à être la "manière la plus concise de faire les choses", mais plutôt à rendre le flux de données évident et lisible

Une grande chose à propos de Redux est qu'il s'agit presque plus d'un modèle de conception que d'un cadre, et tout le code que vous voyez (à part le magasin et react-redux ) est le vôtre.

En regardant Jumpstate (je ne le savais pas jusqu'à présent), c'est l'une des premières couches d'abstraction que je vois pour Redux qui a l'air bien. Super même ! Mais en même temps, cela ne vous éloigne qu'à un cheveu d'autres frameworks comme MobX, et avoir plusieurs frameworks qui apportent la même chose à la table n'est pas très utile. Il est donc important de se concentrer sur ce qui rend Redux différent des autres, pas seulement sur la façon dont nous pouvons améliorer Redux dans le vide (car il vit dans le même monde que les autres outils).

Une autre chose importante, c'est que beaucoup de défis que rencontrent les nouveaux arrivants lorsqu'ils atteignent Redux ne sont pas Redux lui-même, mais JavaScript. D'autres grands frameworks comme Angular éloignent JavaScript lui-même. Écrire un réducteur Redux consiste simplement à appliquer des "modèles de conception" javascript vanille, qui peuvent ne pas être familiers aux nouveaux arrivants, et qui inciteront les gens à vouloir utiliser une boîte noire à la place.

Enfin, de nombreuses bibliothèques de réduction standard essaient d'ajouter une relation 1:1:1 entre les composants, les réducteurs et les créateurs d'actions (peut-être pas les 3, mais souvent 2 d'entre eux), ce qui fait oublier aux nouveaux arrivants qu'ils peuvent avoir plusieurs réducteurs pour gérer une action , plusieurs composants utilisant l'état de plusieurs réducteurs, et ainsi de suite. C'est l'une des questions n°1 auxquelles je réponds au travail et ailleurs, et c'est super utile. Donc, l'outil pour aider dans ce domaine ne devrait pas perdre cela (de plus, "les commutateurs sont dégoûtants" n'est pas le meilleur argument au monde).

Ainsi, IMO, les CTA impliqueraient de lier de bonnes ressources JavaScript vanille, ainsi que de documenter davantage le « pourquoi » tout au long des concepts de « démarrage », et de garder les choses simples. Vous pouvez créer des applications gigantesques dans Redux sans apprendre beaucoup de nouveaux concepts. Bien que je sois moi-même un gars observable par redux, j'ai vu plusieurs centaines de milliers de lignes d'applications de code utilisant Thunk sans problèmes (et j'ai vu de minuscules applications faire un naufrage avec des thunks). Présenter très peu de concepts « de base » et montrer comment ils peuvent être appliqués à des tonnes de concepts aide beaucoup.

Le "tous les passe-partout doivent être réduits, peu importe le coût" est un problème avec la communauté du génie logiciel dans son ensemble de nos jours... c'est plus difficile à résoudre.

Dès le début, ma principale préoccupation avec le redux était que je lisais ou écrivais un code, je devais sauter entre N fichiers, la logique b/c de la seule partie de l'interface utilisateur est dispersée dans toute la base de code entre les actions, les types d'action et plusieurs réducteurs. J'aime beaucoup le fait de pouvoir accéder à n'importe quelle partie de l'arborescence d'état depuis n'importe quel endroit de l'interface utilisateur et de pouvoir modifier les différentes parties de l'état en réponse à une seule action (principales raisons pour lesquelles j'utilise redux), mais plus il y a de parties de plus je change d'état en réponse à une seule action, plus ma logique s'estompe. Je ne peux pas simplement lire ou écrire ce qui s'est passé lorsque l'utilisateur a fait ceci ou cela. Mais ce que je veux, c'est peut être décrit comme ceci:

// meta code
dispatch(ACTION);

onAction = {
  ACTION: [
    // handler 1: hide spinner here,
    // handler 2: change status there,
    // handler 3: update entity
  ],
};

En fin de compte, j'ai trouvé redux-interactions + redux-tree et j'en suis assez content jusqu'à présent.

Approche dans notre projet actuel :

note, serait très différent selon les exigences de l'application :) une fois que nous ajoutons des mises à jour d'objets en temps réel, peut-être que des sagas ou des observables offriraient un avantage par rapport à thunk/promesse

• redux-thunk
• promettre un middleware
• notre "api wrapper", qui est un wrapper autour de l'application de plumes client, service(name, method, ...opts) qui est un créateur d'action avec la charge utile étant une promesse d'appeler notre API (c'est-à-dire que le middleware de promesse le récupère et envoie x_FULFILLED , x_PENDING et x_REJECTED ). pourrait également écraser le nom de l'action pour cela.

Nous utilisons d'abord componentDidMount() pour appeler notre API, stocker les données dans l'état du composant. Cependant, nous utilisons notre enveloppe d'API pour cela, ce qui signifie qu'une action est toujours envoyée (et enregistrée par le middleware de l'enregistreur, y compris la méta qui est une information de demande), et si nous souhaitons ainsi refactoriser en utilisant le magasin pour ce composant tout ce dont nous avons besoin c'est ajouter un réducteur qui écoute sur l'action. Nous commençons par utiliser uniquement l'état local et refactorisons en redux lorsque l'état de ce composant doit être consulté/modifié à partir d'un autre composant. Cela étant dit, je vois l'intérêt d'utiliser redux partout, car il fournit une trace écrite pour tout. Compte tenu de notre équipe actuelle et du calendrier des candidatures, ce n'est tout simplement pas avantageux pour nous atm.

J'ai un peu joué avec redux-saga, mais comme notre flux asynchrone le plus compliqué est la connexion/déconnexion, qui fonctionne (et le code n'est pas très compliqué), ce n'est pas vraiment une raison énorme pour changer (mais cela peut valoir la peine de tester raisons - iterable + mocks est un bon moyen de tester). redux-observable Je ne vois pas l'avantage immédiat à moins que les observables ne soient eux-mêmes bénéfiques, par exemple, si vous souhaitez double-cliquer correctement sur les événements.

Nous nous sommes un peu éloignés du passe-partout en ayant nos propres fonctions d'usine pour renvoyer les réducteurs, et en ayant nos propres réducteurs d'ordre supérieur en plus des fonctionnalités personnalisées (par exemple un réducteur au-dessus du "paginateur" afin que le contenu soit paginé mais puisse avoir des actions pour modifier un élément).

Je pense qu'il faut faire un tutoriel géant à partir d'une application de réaction de base, démontrer les problèmes qui surviennent avec la communication entre les composants, puis introduire le redux, puis continuer, en démontrant les problèmes qui se produisent dans des situations spécifiques, et comment ils peuvent être aidé avec redux-x . C'est-à-dire un guide pour savoir quand et quoi utiliser. Il y a certainement des articles de blog qui existent avec des discussions dans ce sens.

Ce qui est également pertinent, c'est mon résumé que j'ai proposé pour les modèles utilisés dans gothinkster/react-redux-realworld-example-app

La plupart des gens que je connais qui utilisent fortement redux, finissent par s'éloigner de redux-thunk car ils trouvent qu'il ne s'adapte pas très bien

Je comprends ce que vous dites, mais voici ma préoccupation inverse : nous voyons de plus en plus de preuves anecdotiques qu'un énorme groupe de développeurs JS n'utilise même pas encore les _fonctions de flèche_ et d'autres fonctionnalités de base ES (6|2015) , en raison d'un manque de compréhension, d'intimidation, etc. Attendre des gens qui veulent se lancer avec Redux et qui pourraient tirer profit de l'apprentissage des _modèles_ introduits par Redux, pour apprendre d'abord des observables ou des générateurs, c'est probablement trop demander ?

Redux-thunk est également légèrement complexe dans le sens où le redux middleware en général fait plier votre cerveau, mais il ne s'agit au moins que de fonctions/rappels, qui sont faciles à saisir si vous écrivez du JS. J'aime vraiment l'idée d'avoir un ensemble complet d'outils connexes pour commencer, disponibles via un seul téléchargement, même s'il est présenté comme "learn-redux" au lieu de "best-practice-always-redux". Semblable à la façon dont create-react-app doit être peaufiné à mesure que vous apprenez tout ce qu'il a configuré pour vous, cela pourrait encourager votre propre peaufinage, peut-être montrer comment convertir une simple configuration redux-thunk en utilisant des sagas, etc. comme sa propre forme d'"éjecter"...

Juste quelques réflexions.

Je comprends ce que vous dites, mais voici ma préoccupation inverse : nous voyons de plus en plus de preuves anecdotiques qu'un énorme groupe de développeurs JS n'utilise même pas encore les fonctions de flèche et d'autres fonctionnalités ES(6|2015) de base , en raison d'un manque de compréhension, d'intimidation, etc. Attendre des gens qui veulent commencer avec Redux et qui pourraient bénéficier de l'apprentissage des modèles introduits par Redux pour apprendre d'abord des observables ou des générateurs est probablement trop demander ?

Bingo ! Nous sommes dans un environnement où BEAUCOUP de gens sont nouveaux avec JS (ou ils « connaissent » JS, mais ce n'est pas leur spécialité, et ils commencent par le fond). Surtout si ces gens sont des ingénieurs logiciels expérimentés d'un autre écosystème (java, rails, etc.), ils essaieront rapidement d'appliquer les concepts qu'ils connaissent avant d'apprendre ceux qu'ils ne connaissent pas, et cela ne fonctionnera pas tout à fait et ils resteront bloqués. Je ne sais pas quelle est la meilleure façon de convaincre les gens d'acquérir une compréhension approfondie de JS avant de se lancer dans un modèle de conception UX fonctionnel.

Notez que les docs Redux ont une section sur la réduction de Boilerplate pour ceux d'entre vous qui lisent qui recherchent quelque chose maintenant et ne veulent pas adopter une bibliothèque entière au-dessus de Redux.

Nous devrions être un peu prudents à propos de cette discussion et réaliser que cela a probablement déjà été beaucoup modifié. L'équipe Redux a entendu, considéré et rejeté beaucoup de choses qui seront probablement proposées ici. Il est fort possible que rien ne sorte de cette discussion si nous ne nous battons que sur des choses qui ont déjà été discutées.

Cela étant dit, je pense que c'est une excellente idée de parler des moyens de rendre le framework plus accessible à tous (nouveaux et expérimentés).

Tout ce que vous proposez de réduire le passe-partout doit être tel qu'il soit possible de revenir à ce qui se trouve sous l'abstraction chaque fois que cela est nécessaire. Ce n'est pas amusant d'adopter une abstraction juste pour l'abandonner plus tard pour revenir au niveau inférieur parce que vous aviez besoin d'une chose supplémentaire à laquelle les auteurs de l'abstraction n'ont pas pensé.

La courbe d'apprentissage Redux peut être raide, mais une fois que vous avez compris les concepts, le besoin de
les couches d'abstraction disparaissent souvent

Je me demande, si c'est le cas, quelles parties de Redux suggérons-nous d'améliorer ? Quelles parties supprimeriez-vous ou supprimeriez-vous que vous n'auriez pas besoin de rajouter immédiatement ?

Voici un diagramme de l'ensemble du cycle de vie de réaction/redux que j'ai fait pour une conférence au travail il y a environ un an :

Il y a pas mal de parties de cela, mais je ne peux pas imaginer que Redux fonctionne aussi bien sans aucune d'entre elles. Les conteneurs sont parfois un peu ennuyeux, mais si vous les supprimez, vous associez profondément votre logique de vue à votre disposition de données. Si vous supprimez des actions, vous redevenez MVC, ce qui ne sert à rien d'utiliser Redux en premier lieu. La "vue" de ce diagramme existe déjà à peine car elle peut être modélisée comme une simple fonction qui s'abonne au magasin et rend les composants réactifs.

Je ne pense pas qu'il y ait beaucoup de passe-partout à supprimer dans le cadre global lui-même. Vous faites peut-être référence à des éléments passe-partout dans les différentes parties du cadre, comme les créateurs, les réducteurs ou les conteneurs en action. Dans ce cas, les conseils de la page Réduire la plaque signalétique mentionnée ci-dessus traitent déjà de la plupart de ces éléments. Nous n'avons besoin de rien en plus pour le rendre « meilleur ». (Remarque : ce n'est pas que je ne suis pas prêt à ajouter quelque chose pour améliorer les choses, je ne le vois pas encore.)

Peut-être qu'il ne s'agit pas tant d'un problème de réduction du passe-partout qu'un problème d'amélioration de l'éducation Redux. Si le framework est difficile à comprendre pour les débutants, nous devrons peut-être améliorer la documentation Redux et la rendre plus accessible. Peut-être que certains des conseils de réduction passe-partout doivent être annoncés de manière plus agressive dans les documents.

Réduire le nombre d'étapes nécessaires (passerelle) ne résout pas toujours le problème. Pour insister sur mon point depuis le tout début de mon article, vous ne voulez pas écrire une abstraction qui sera jetée parce que vous n'avez pas pensé à toutes les manières dont les gens auraient besoin de l'utiliser.

Quelques bonnes discussions jusqu'à présent. Laissez-moi jeter quelques exemples rapides de plaintes courantes liées au "passe-partout" que je vois :

• « Pourquoi dois-je écrire des fonctions de « créateur d'action » juste pour renvoyer un objet immédiatement ? »
• "Je dois toucher tellement de fichiers juste pour ajouter une nouvelle fonctionnalité simple ! De plus, je répète sans cesse les mêmes noms pour les constantes et les noms de fonctions et..."
• « Pourquoi ai-je besoin de ces 'intergiciels' juste pour passer un appel AJAX ? »
• « Pourquoi dois-je utiliser des instructions switch pour tout ? »
• « Pourquoi ai-je besoin de ce truc de dispatch ? Pourquoi dois-je regrouper toutes ces fonctions pour les faire fonctionner ? »

Et quelques exemples spécifiques de ces types de commentaires :

• La mise en œuvre de Redux est fastidieuse.
• Configuration minimale de Redux
• Jumpstate README et Jumpstate + Redux + CRA - aucun envoi ou créateur d'action nécessaire !

Et pour jeter immédiatement quelques réponses à ces préoccupations " passe-partout " : sur ces cinq catégories répertoriées, seule " l'utilisation de dispatch " est en fait _requis_. Pour le reste:

• Vous n'êtes pas obligé d'utiliser des créateurs d'action, mais c'est une bonne pratique pour la cohérence (selon mon article Idiomatic Redux : Pourquoi utiliser des créateurs d'action ? )
• Vous n'avez pas besoin d'avoir des fichiers complètement séparés pour les créateurs d'action, les constantes d'action et les réducteurs. Le modèle « canards » est une approche populaire pour rassembler tous ces éléments dans un seul fichier. Cela a l'inconvénient de "cacher" la possibilité que plusieurs réducteurs écoutent une action. Redux ne se soucie finalement pas de la structure de votre fichier.
• Vous _pouvez_ effectuer un travail asynchrone en dehors de Redux complètement, comme dans un composant. Mais, selon la description de Dan à Pourquoi avons-nous besoin d'un middleware pour le flux asynchrone dans Redux ? , il est généralement bon d'extraire cette logique en dehors des composants, et le middleware fournit une "échappatoire" pour effectuer un travail asynchrone tout en ayant accès au magasin Redux.
• Vous n'êtes certainement pas obligé d'utiliser des instructions switch dans les réducteurs, elles ne sont que le moyen le plus "évident" de gérer plusieurs valeurs pour une variable donnée. Les tables de recherche, les instructions if/else et tout ce que vous voulez sont parfaits (par FAQ : dois-je utiliser des instructions switch ? )
• Vous devez réellement appeler store.dispatch() pour que quelque chose d'utile se produise - c'est une décision de conception de base de Redux. La liaison des créateurs d'actions permet de les transmettre à des composants enfants non connectés et de les faire distribuer chaque fois que la fonction est appelée.

Donc, dans l'ensemble, il n'y a presque rien de ces problèmes de "passe-partout" qui soit _requis_. C'est une combinaison d'exemples tirés de la documentation et de "bonnes pratiques de programmation" comme la déduplication du code et la séparation des préoccupations.

Je pense que les questions posées par @markerikson sont vraiment justes et je me les ai également posées à un moment donné dans le passé.

Redux est en quelque sorte une bibliothèque de "bas niveau" pour la modélisation de données. Comme toute bibliothèque de bas niveau, elle expose beaucoup de choses que vous pouvez facilement faire abstraction afin de prendre en compte la majorité des cas. Je pense que la raison pour laquelle

Peut-être devrions-nous considérer que la bonne voie pourrait être de développer et de stabiliser une bonne bibliothèque au-dessus de Redux (comme Jumpstate ?). Nous commençons par enseigner cela aux gens, puis leur donnons un moyen facile d'utiliser Redux directement quand ils en ont besoin.

Je ne pense pas que Redux ait besoin de beaucoup plus dans sa base de code principale et je ne vois aucune partie de celui-ci qui doive être abstraite de manière permanente. (Si vous le faites, faites le moi savoir :smile:) À mon avis, il n'y a pas grand-chose à gagner à ajouter ou à supprimer des éléments du noyau Redux.

Améliorer une bibliothèque jusqu'à ce qu'elle soit suffisamment stable et flexible pour que tout le monde puisse l'utiliser est probablement une meilleure option. Comme vous l'avez dit, peu de "passe-partout" est réellement nécessaire , alors débarrassons-nous-en dans une bibliothèque au-dessus de Redux au lieu de modifier Redux lui-même.

Un exemple de ce qui se passe dans une autre communauté est le langage de programmation Rust. Il existe une bibliothèque IO non bloquante pour le langage de programmation Rust appelée "mio" . Il se concentre sur le fait d'être petit et de bas niveau, tout comme le fait Redux. Le fait est que pratiquement personne ne l'utilise directement parce que ce serait vraiment difficile et plein de passe-partout. Presque tout le monde utilise une autre bibliothèque appelée tokio qui s'appuie sur mio et la rend extrêmement utilisable et ergonomique. De cette façon, toute personne qui a besoin de la plomberie de mio peut l'utiliser directement, mais toute personne qui veut juste faire quelque chose rapidement peut utiliser tokio.

Nous devrions adopter un modèle similaire.

Pour développer quelques commentaires de

Il y a eu un commentaire récent dans #775 qui, je pense, capture bien les choses :

Redux est un framework générique qui offre un équilibre entre juste assez de structure et juste assez de flexibilité. En tant que tel, il fournit une plate-forme permettant aux développeurs de créer une gestion d'état personnalisée pour leurs cas d'utilisation, tout en étant capable de réutiliser des éléments tels que le débogueur graphique ou le middleware.

Alors oui, Redux est "juste un modèle" à bien des égards. La bibliothèque de base est vraiment complète - les seuls vrais changements semi-planifiés sont des choses comme la restructuration de l'enrichisseur proposée ( #1702, #2214 ), et peut-être rendre combineReducers plus flexible ( #1768 , #1792 , etc. ).

Près de deux ans se sont écoulés depuis la création de Redux, et nous avons maintenant une assez bonne idée de la façon dont les gens l'utilisent. À titre d'exemple, @jimbolla a rassemblé une liste de tous les amplificateurs de magasin connus dans #2214 , et a catégorisé leur fonctionnement et leur utilisation. Je suis toujours un grand fan de la simplicité et de la flexibilité de Redux, mais j'aimerais voir des abstractions encore idiomatiques au-dessus de Redux qui simplifieraient l'utilisation générale et résoudraient les problèmes des gens.

Un autre ensemble de sujets semi-liés, et quelque chose pour lequel j'ai un intérêt personnel distinct, sont les idées de "logique/composants encapsulés" (par @slorber "frontend évolutif avec Elm/Redux" terrain de jeu ) et "plug -and-play Redux setup" (comme on le voit dans des expériences comme https://github.com/brianneisler/duxtape/issues/1 , https://github.com/jcoreio/redux-features/issues/7 , etc). La configuration globale de l'état et de l'application est idéale pour certains cas d'utilisation, mais pas tellement pour d'autres.

En tant que point connexe intéressant, @toranb a fait un excellent travail en créant un wrapper Ember pour Redux à l' adresse https://github.com/ember-redux/ember-redux . Le monde Ember est _vraiment_ en "convention sur la configuration", et donc ember-redux met en place une configuration de magasin par défaut raisonnable, y compris redux-thunk et autres. Une approche comme celle-là pourrait être utile.

Alors oui, je lance en quelque sorte tout un tas de pensées différentes ici, mais elles sont liées de diverses manières. Dans l'ensemble, je souhaite réduire les obstacles à l'apprentissage et à l'utilisation de Redux, et permettre des cas d'utilisation plus avancés à tous les niveaux.

Redux est une API générale, non spécialisée. Cela le rend plus détaillé, tout en couvrant plus de cas. Sa puissance réside dans un logiciel complexe, alors que tout projet nouveau ou simple dépasse le cadre de la nécessité.

Cependant, vous pouvez créer des spécialisations au-dessus des API générales. Par exemple, j'utilise https://github.com/acdlite/redux-actions qui réduit le passe-partout pour les cas courants. J'utilise toujours toute la puissance de redux et le simple fait d'avoir cette interface ne suffirait pas à mes besoins.

L'autre problème est que les nouvelles personnes qui n'ont pas connu la douleur d'applications incroyablement compliquées se demandent à quoi cela sert. Eh bien, pour eux, ils ne devraient probablement même pas utiliser le redux jusqu'à ce qu'ils aient ressenti cette douleur, mais la série Egghead de Dan peut les faire passer assez facilement au-delà de ce point.

https://egghead.io/courses/getting-started-with-redux
https://egghead.io/series/building-react-applications-with-idiomatic-redux

Référence : Le spectre de l'abstraction : https://www.youtube.com/watch?v=mVVNJKv9esE

Comme mentionné - redux-actions est assez bon pour supprimer certains passe-partout, supprimer les constantes de l'équation en attachant .toString est une idée vraiment intéressante que j'aime, mais je préfère écrire cette logique moi-même que d'utiliser redux-actions moi-même, mais c'est un choix personnel pour garder mon code plus petit.

À mon humble avis, il devrait y avoir un mécanisme intégré (argument de rappel de subscribe ?) à l'extérieur, c'est-à-dire par composants ou connect )

J'enseigne souvent le redux aux autres et cela peut être assez intimidant pour les raisons suivantes

• De nombreuses pièces mobiles : magasin, état, réducteurs, créateurs d'actions, actions, actions asynchrones, middleware, composants connectés
• Bibliothèques. Pour une application simple qui parle à une API REST dont vous avez besoin : redux, react-redux, redux-thunk (ou autres) + des bibliothèques supplémentaires si vous voulez tester des choses
• Nombre d'endroits où vous devez mettre du code (voir _pièces mobiles_)

Je pense que redux est une excellente bibliothèque qui a tout son sens en soi et je pense qu'elle a de grandes abstractions et est super évolutive lorsqu'elle est utilisée correctement. J'apprécie également que redux puisse être utilisé avec n'importe quelle bibliothèque d'interface utilisateur, mais je pense que dans la majorité des cas, il sera utilisé avec react.

En général, je crois que beaucoup de frustration vient des nombreuses pièces mobiles.

Voici quelques réflexions que j'ai eues. Tout cela peut être construit sur redux afin qu'il puisse rester tel qu'il est.

• Fournissez une bibliothèque telle que react redux, qui prend également en charge les actions asynchrones intégrées.
• De nombreuses actions asynchrones communiquent avec une API REST, alors fournissez un middleware idiomatique pour cela
• Écrivez les composants intelligents en tant que composants réels au lieu d'utiliser connect. Ils peuvent ensuite rendre les composants stupides dans leur méthode render
• Prescrire une disposition de fichier évolutive pour les _composants de conteneur_, les _composants intelligents_, les _composants muets_, les _créateurs d'action_ et les _réducteurs_.
• Fournissez un _redux-cli_ pour générer du code, par exemple redux action loadUsers
• Standardisez sur une couche asynchrone comme redux-saga ou redux-observable et incluez-la dans la documentation (ce serait bien d'avoir _un_ endroit à consulter pour la plupart des problèmes de redux)
• par défaut, les fonctionnalités de langage étendues (par exemple les décorateurs (@connect)) ou TypeScript pour rendre les choses moins verbeuses en particulier mapStateToProps et mapDispatchToProps (mobx nécessite des décorateurs et la syntaxe est simple)

T

D'accord, redux-actions est un bon exemple de quelques abstractions simples qui suppriment le passe-partout.

Laissez-moi vous poser la question suivante : Create-React-App a le package react-scripts , qui contient des configurations Babel et Webpack prédéfinies, et est livré avec un tas de paramètres par défaut intégrés. À quoi pourrait ressembler un package redux-scripts ?

Je suis d'accord avec certains des autres commentaires (négatifs) sur redux-thunk . Je ne le recommanderais pas aux débutants (je ne le recommanderais probablement plus du tout):

1. Cela semble magique pour commencer.
2. Cela n'enlève pas vraiment beaucoup de passe-partout. Étant donné un processus asynchrone plus complexe, devoir obtenir dispatch des props et le transmettre ne représente qu'une petite partie du code.
3. Il en résulte des créateurs d'action que vous ne pouvez pas composer ensemble dans des workflows plus importants.
4. Un dernier point que je ne peux pas très bien articuler à propos de la transformation du style redux en un framework plutôt qu'une bibliothèque : vous comptez sur le framework pour appeler votre code, plutôt que d'appeler la bibliothèque.

Nous l'avons utilisé assez largement dans une application React-Native, et c'était surtout utile, mais nous avons eu du mal à composer des actions ensemble (pensez à "charger le profil après une connexion réussie"), en raison des créateurs d'actions redux-thunk renvoyant effectivement void (c'est-à-dire n'avoir rien de tel qu'une promesse à utiliser pour séquencer la prochaine action).

Cela a tendance à encourager les gens à penser que "la seule façon de faire quelque chose est de dispatch immédiatement à partir du gestionnaire d'événement/rappel React". Et puisque nous utilisions connect partir de react-redux et que nous nous appuyions fortement sur mapDispatchToProps , nous avions tendance à oublier que nos gestionnaires d'événements pouvaient simplement être des fonctions simples.

(notez que l'application ci-dessus a été principalement écrite au début de l'année dernière, et nous n'avons pas vraiment suivi ce qui se passait dans le grand écosystème Redux, il est donc peut-être obsolète).

@bodhi : sans aller trop loin, je serais en désaccord avec certaines de ces conclusions. redux-thunk fait 11 lignes, et il y a quelques bonnes explications comme "Qu'est-ce qu'un Thunk ?" . Thunks _are_ composable dans _une_ mesure, et je pense qu'il est généralement plus facile de dire à quelqu'un "écrivez ces quelques lignes de déclarations de fonction, puis faites vos appels AJAX et autres ici". J'ai un article qui traite de certains des différents compromis de thunks (et dans une certaine mesure des sagas) chez Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability .

Je suis d'accord sur le fait qu'il devrait y avoir un moyen "béni" ou "intégré" de gérer les effets secondaires dans une couche d'abstraction hypothétique. Les sagas et les observables sont tous les deux formidables, _si_ vous comprenez comment les utiliser. Je ne sais tout simplement pas s'ils seraient appropriés, étant donné qu'un objectif potentiel ici est de fournir un chemin d'accès facile à l'apprentissage et à l'utilisation de Redux.

Je trouve qu'utiliser redux-thunk ne consiste pas seulement à faire quelque chose de manière asynchrone, mais aussi à faire quelque chose qui dépend de l'état actuel. Interface très propre et simple, et encourage l'utilisation de créateurs d'action.

Bodhi : Peut-être un peu hors sujet, mais j'ai juste pensé qu'il vaut peut-être la peine de mentionner que l'envoi ne renvoie pas le vide, il renvoie le résultat de votre fonction intérieure. Ainsi, si vous retournez par exemple une promesse, vous pouvez facilement enchaîner les actions. Voir la section sur la composition dans le readme :
https://github.com/gaearon/redux-thunk/blob/master/README.md

En dehors de cela, je voudrais juste remercier la communauté pour cette discussion ouverte, très intéressante pour entendre les pensées et les idées de chacun.
Personnellement, je m'en tiens aux idées jusqu'à présent, mais en essayant de séparer clairement "ce qui s'est passé" de "comment l'état devrait-il changer". Je vois pas mal d'exemples dans notre code où nous faisons cette erreur (en utilisant des actions pour dire aux réducteurs quoi faire, au lieu que les réducteurs réagissent simplement à ce qui s'est passé), donc ce serait bien de voir une bibliothèque qui rendrait cela plus difficile à do (pas encore vendu sur les sagas).

Le 19 mars 2017, à 23h48, Bodhi [email protected] a écrit :

Je suis d'accord avec certains des autres commentaires (négatifs) sur redux-thunk. Je ne le recommanderais pas aux débutants (je ne le recommanderais probablement plus du tout):

Cela semble magique pour commencer.
Cela n'enlève pas vraiment beaucoup de passe-partout. Compte tenu d'un processus asynchrone plus complexe, le fait de devoir obtenir la répartition des accessoires et de la transmettre ne représente qu'une petite partie du code.
Il en résulte des créateurs d'action que vous ne pouvez pas composer ensemble dans des workflows plus importants.
Un dernier point que je ne peux pas très bien articuler à propos de la transformation du style redux en un framework plutôt qu'une bibliothèque : vous comptez sur le framework pour appeler votre code, plutôt que d'appeler la bibliothèque.
Nous l'avons utilisé assez largement dans une application React-Native, et c'était surtout utile, mais nous avons eu du mal à composer des actions ensemble (pensez à "charger le profil après une connexion réussie"), en raison des créateurs d'actions redux-thunk renvoyant effectivement void (c'est-à-dire ayant rien de tel qu'une promesse à utiliser pour séquencer la prochaine action).

Cela a tendance à encourager les gens à penser que "la seule façon de faire quoi que ce soit est d'envoyer immédiatement à partir du gestionnaire d'événements/rappel React". Et puisque nous utilisions connect de react-redux et que nous nous appuyions fortement sur mapDispatchToProps, nous avions tendance à oublier que nos gestionnaires d'événements pouvaient simplement être des fonctions simples.

(notez que l'application ci-dessus a été principalement écrite au début de l'année dernière, et nous n'avons pas vraiment suivi ce qui se passait dans le grand écosystème Redux, il est donc peut-être obsolète).

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

(désolé de continuer la tangente, mais...)

il convient de mentionner que l'envoi ne renvoie pas void, il renvoie le résultat de votre fonction interne.

Euh, super ! Je suppose que je n'ai jamais regardé de trop près la documentation avant d'essayer de trouver un autre moyen de résoudre nos problèmes.

La chose la plus précieuse qui a rendu Redux tellement plus facile pour moi est de traiter les actions comme des événements et non comme des commandes . Cela élimine complètement la lutte pour décider comment concevoir des actions et quoi y mettre.

Les composants n'ont pas besoin de savoir comment l'interaction de l'utilisateur doit affecter l'état, ils disent seulement au monde extérieur ce qui s'est passé à l'intérieur d'eux, par exemple "bouton X cliqué" . Lorsque vous utilisez des actions en tant que commandes, vous introduisez effectivement une liaison bidirectionnelle entre le composant et l'état.

Les réducteurs ne sont pas liés aux composants, ils représentent l' état de l'application et non l' état du composant , et ils sont la seule partie qui sait réellement comment l'état change. Il n'y a pas de barrière cognitive dans la gestion d'une action unique dans plusieurs réducteurs, car une action n'est pas une déclaration "que faire avec l'état" .

Cela supprime également tout cas de répartition synchrone de plusieurs actions.

Tout cas d'envoi d'une action unique à partir de plusieurs endroits disparaît également. Vous pouvez garder les créateurs d'action à proximité du composant, ce qui facilite le suivi du composant qui a envoyé l'action.

En consultant le journal des actions dans DevTools, vous pouvez voir un historique complet de ce qui s'est passé dans votre application et il est facile de voir la tranche d'état concrète affectée par l'action. L'histoire reste la plus courte possible.

Cette approche basée sur l'extraction rend le flux de données vraiment unidirectionnel et s'empile naturellement avec des bibliothèques de gestion des effets secondaires telles que redux-saga ou redux-observable .

@aikoven bien que je sois totalement d'accord avec cela (il y a eu certainement beaucoup de discussions dans le passé comparant le redux à l'approvisionnement d'événements), que faites-vous avec des choses comme FETCH_USER , ce qui est très courant à voir (et quelque chose qui doit être fait). Cela semble plus "semblable à une commande" qu'à "un événement".

@blocka Il y a toujours un événement qui entraîne une demande de réseau. La requête elle-même peut être encapsulée dans des actions FETCH_USER_STARTED et FETCH_USER_DONE / FETCH_USER_FAILED , c'est ainsi que le résultat de la requête se retrouve dans l'état.

👍 pour redux-actions

Ce que j'aime aussi, à part la réduction du passe-partout, c'est que cela ressemble à une extension très naturelle du redux. Pour quelque chose comme jumpstate je sens que l'implémentation va un peu plus loin, et maintenant je vais devoir apprendre deux choses au lieu d'une.

Ce que je veux dire, c'est que tous les plugins que nous ajoutons pour réduire la plaque signalétique devraient ressembler beaucoup à du travail avec redux, bien qu'avec une API moins détaillée.

Une grande partie du passe-partout est le même passe-partout que vous avez dans n'importe quel environnement. Lorsque vous rencontrez une duplication, nous la résolvons généralement avec une abstraction personnalisée. Ces abstractions ne sont, très souvent, pas utiles en dehors de votre projet actuel, et une « solution miracle » ne peut tout simplement pas exister. Les exigences de chaque projet sont différentes.

Même chose avec le redux. Si vous avez besoin d'une action FETCH_X_STARTED , et d'un créateur d'action fetchX() et d'un réducteur pour gérer cela, etc., n'hésitez pas à créer votre propre abstraction !

Blâmer le redux pour le passe-partout, c'est comme copier et coller tout votre code, puis reprocher à Javascript d'avoir trop de passe-partout.

Je trouve que l'utilisation de redux-thunk ne consiste pas seulement à faire quelque chose de manière asynchrone, mais aussi à faire quelque chose qui dépend de l'état actuel. Interface très propre et simple, et encourage l'utilisation de créateurs d'action.

L'utilisation de redux-thunk pour le code synchrone n'est pas une bonne idée et doit être mentionnée dans la documentation.
Si vous composez plusieurs fonctions ensemble, vous n'êtes pas certain que le flux d'expédition ne dépend pas de l'ordre, il est donc plus difficile de raisonner et de tester.

Il me semble préférable d'avoir des créateurs d'actions purs et d'utiliser simplement le batching d'actions pour des modifications d'état plus complexes. De cette façon, vous n'avez que des fonctions pures à tester.

Je recommande cet article de blog pour mieux comprendre : http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/

@Machiaweliczny merci pour l'article. Je suppose que la question pour moi est plus de savoir où vous finissez par mettre votre logique métier (comme discuté dans https://medium.com/@jeffbski/where -do-i-put-my-business-logic-in-a- réagir-redux-application-9253ef91ce1#.3ce3hk7y0). Vous ne dites pas que votre flux de répartition (thunk, épique, saga, peu importe) ne devrait jamais avoir accès à l'état actuel de l'application, n'est-ce pas ?

@dfbaskin

Gardez à l'esprit que Redux n'est pas un développement axé sur le domaine. La « logique métier » est une préoccupation très floue ici, et il s'agit plutôt de « quelle signature de fonction du concept correspond le mieux à la logique que j'essaie de mettre en œuvre ». Votre « logique métier » est répartie entre les sélecteurs, les réducteurs, les créateurs d'actions et les « orchestrateurs » (avons-nous encore un meilleur mot pour cela ?) en fonction de vos besoins.

Le réducteur, étant (state, action) => state est l'endroit où la "logique qui dépend de l'état" devrait généralement être. Et bien sûr, dans des choses comme l'architecture Elm, toute cette logique est dans la fonction "mise à jour" (l'équivalent de notre réducteur).

Malheureusement dans Redux, le réducteur ne peut jamais gérer que la logique synchrone. Ainsi, la "logique métier" asynchrone qui dépend de l'état doit soit l'obtenir du composant via le dispatch (si le composant a cette information, ce qui n'est pas toujours le cas), soit via le concept d'orchestrateur de votre choix (thunk, sagas, epic), qui ont accès à l'état pour cela.

S'il n'y avait pas eu la limitation du réducteur, il n'y en aurait pas besoin. Vous le voyez en fait lorsque les gens utilisent redux-saga ou redux-observable : leurs actions/créateurs d'actions deviennent généralement presque insignifiants (dans la plupart des cas, plus ou moins une normalisation ou un formatage), et la saga/épopée sont presque des "réducteurs alternatifs" , sur cela, vous avez maintenant une autre chose qui a accès à l'action et à l'état et renvoie une "chose", et la complexité du réducteur réel est diminuée en conséquence. Les réducteurs et les orchestrateurs sont très étroitement liés (parfois trop étroitement, et ce n'est pas génial d'avoir 2 constructions interchangeables la moitié du temps... mais c'est ce que nous avons, autant en profiter)

@Machiaweliczny : en tant qu'auteur de ce post "Pensées sur Thunks", je peux vous assurer que "éviter d'utiliser des thunks pour un travail synchrone" est le contraire de ce que j'essayais de dire :)

Plus de bonnes discussions, mais nous commençons à nous éloigner un peu du sujet. (C'est un hangar à vélos que je vois là-bas ? :) )

Permettez-moi de revenir sur les questions initiales :

• À quoi ressemblerait l'utilisation idiomatique de Redux avec "moins de passe-partout" ? Comment pouvons-nous apporter des solutions à ces plaintes?
• Quelles abstractions possibles pourraient être créées pour simplifier le processus d'apprentissage et d'utilisation, mais sans masquer réellement Redux (et fourniraient, espérons-le, un chemin de migration/d'apprentissage pour « base » Redux) ?
• Dans quelle mesure cela pourrait-il être résolu avec des documents améliorés d'une manière ou d'une autre ?

Quelles mesures concrètes pouvons-nous mettre en œuvre pour y remédier ?

Dans le domaine des étapes non controversées, exploitables et à court terme, je dirais :

1) Rendre le magasin plus facile à configurer (peut-être avec une configuration par défaut ? Je ne sais pas si c'est toujours le cas, mais Elm avait un type "démarrer l'application" et un type d'application standard. L'application de démarrage était utilisée pour des applications simples et dans du matériel de formation pour couvrir les 90 % des cas où les gens ne font qu'apprendre. À ce jour, j'admets que je ne peux pas configurer le magasin Redux avec des middlewares de base (devtools, thunks) sans rechercher la doc pour les signatures. Je ne pense pas que beaucoup de gens diraient que les nouveaux arrivants doivent savoir comment configurer les middlewares d'un magasin pour apprendre les concepts de base de Redux.

2) Cela peut déjà être le cas, assurez-vous que l'ajout de Redux avec le "starter store" ci-dessus pour create-react-app est aussi simple que possible, afin qu'un nouveau venu puisse avoir une application Redux opérationnelle en 2 minutes.

Je pense que cela nous mènerait très, très loin.

Edit : par application de démarrage, je ne veux pas dire une application passe-partout, mais plutôt un "createStore" qui ne peut pas être configuré mais qui a des valeurs par défaut raisonnables que les gens peuvent simplement importer et en finir avec. Ensuite, ils peuvent simplement passer au "vrai" createStore lorsqu'ils le dépassent.

Cela ressemble à un concept assez fantastique là.

Le lun 20 mars 2017 à 10h02 François Ward [email protected]
a écrit:

Dans le domaine des étapes non controversées, exploitables et à court terme, je dirais :

1.

Facilitez la configuration du magasin (peut-être avec une valeur par défaut
configuration? Je ne sais pas si c'est toujours le cas, mais Elm avait l'habitude d'avoir
un type « démarreur » et un type d'application standard. L'application de démarrage a été utilisée pour
des applications simples et du matériel de formation pour couvrir les 90 % des cas où les gens sont
juste apprendre. À ce jour, j'admets que je ne peux pas configurer le magasin Redux
avec des middlewares de base (devtools, thunks) sans rechercher la doc pour
les signatures. Je ne pense pas que beaucoup de gens diraient que les nouveaux arrivants ont besoin
savoir configurer les middlewares d'une boutique pour apprendre le core Redux
notions.
2.

Cela peut déjà être le cas, assurez-vous d'ajouter Redux avec ce qui précède
"starter store" pour créer-réagir-application est aussi simple que possible, donc un nouveau venu
peut avoir une application Redux opérationnelle en 2 minutes.

Je pense que cela nous mènerait très, très loin.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/reactjs/redux/issues/2295#issuecomment-287806663 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AFUmCQYkUwjkCugevDBWC8TOu0HhWJTnks5rnqMWgaJpZM4MhnVF
.

Nos modules utilisent combineReducers pour que chaque tranche d'état d'un module ait un réducteur dédié (je crois que cette approche est décrite dans la section Structuring Reducers de la documentation, alias "slice

const { makeIndicator, makePayloadAssignor } from '../shared/reducers';

const searchModule = combineReducers({
  searching: makeIndicator(c.SEARCH),
  results: makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

Peut-être que l'identification de réducteurs de tranches plus courants comme celui-ci serait un bon moyen d'atténuer les problèmes passe-partout, où ils pourraient servir de blocs de construction primitifs pour nos réducteurs.

Il s'agit d'une refactorisation Javascript de base. Comme je l'ai déjà dit... "javascript" a un
beaucoup de "passe-partout", jusqu'à ce que vous appliquiez des choses comme l'abstraction à votre code.

Redux est juste du javascript. Il n'y a rien de magique là-dedans.

Le lun 20 mars 2017 à 12h44, Markus Coetzee [email protected]
a écrit:

Nos modules utilisent des CombineReducers pour que chaque état tranche dans un
module a un réducteur dédié (je crois que cette approche est décrite
dans la section Réducteurs de structuration de la documentation, alias "slice
réducteurs"). Cela rend les choses plus faciles à raisonner car le commutateur
les déclarations sont beaucoup plus petites. Il a également permis à des réducteurs communs d'émerger
dans notre base de code. Les réducteurs les plus simples étaient identiques dans tous les modules
à l'exception de leurs types d'action, nous avons donc pu réduire le passe-partout de
ayant des fonctions auxiliaires (usines de réducteurs ?) qui rendent ces réducteurs pour
nous par type d'action :

const { makeIndicator, makePayloadAssignor } de '../shared/reducers' ;
const searchModule = combinerRéducteurs({
recherche : makeIndicator(c.SEARCH),
résultats : makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

Peut-être qu'identifier des réducteurs de tranches plus courants comme celui-ci serait une bonne
moyen d'atténuer les préoccupations standard, où ils pourraient servir de
blocs de construction primitifs pour nos réducteurs.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/reactjs/redux/issues/2295#issuecomment-287820595 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AACourLpL5--NJiRzrWmKFJ31cl5DXJrks5rnqzxgaJpZM4MhnVF
.

Je suis d'accord avec la plupart des commentateurs qui disent qu'il vaut mieux expliquer les schémas de redux communs que de développer un réducteur passe-partout. Mes coéquipiers et moi avons commencé à travailler avec redux il y a un an et demi et étions pour la plupart confus au sujet des choses les plus simples : ce redux est principalement une source d'événements, qu'une même action peut être gérée par plusieurs réducteurs, cette action peut contenir toute l'entité commerciale non seulement son identifiant , que les réducteurs ne sont que des fonctions et que vous êtes libre de faire tout ce que vous voulez avec eux - composer, générer, diviser, etc. Nous avons commis des erreurs courantes - utilisé des actions comme commandes à distance et nous nous sommes demandé pourquoi ne pas utiliser l'appel de méthode classique ; créé d'énormes middlewares et évité redux-saga parce que "les générateurs sont trop compliqués" (bien que redux-saga soit superbe !), créé de longs fichiers avec d'énormes commutateurs. Ceci est bien sûr dû à des compétences de programmation médiocres mais aussi à cause du manque d'informations structurées. Aujourd'hui la documentation est bien meilleure, merci beaucoup aux mainteneurs !

C'est un sujet très précieux sur Redux en tant que bibliothèque.

Il s'agit d'une refactorisation Javascript de base. Comme je l'ai déjà dit... "javascript" a un
beaucoup de "passe-partout", jusqu'à ce que vous appliquiez des choses comme l'abstraction à votre code.
Redux est juste du javascript. Il n'y a rien de magique là-dedans.

Parfait, @blocka ! Je pense que ce message doit être diffusé.

Redux se sent inhabituel et passe-partout pour les gens en raison de son approche minimale. Minimal semble bizarre pour un "framework" en général (code minimal, principes minimaux).

Certaines personnes ont l'habitude d'écrire du code "framework-y" plutôt que d'écrire du JavaScript lui-même. Lorsque les développeurs utilisent un framework, une manière intégrée de faire les choses est implicitement attendue. Triste comme l'enfer mais vrai.

Je pense que Redux est de plus en plus facile à démarrer, mais nous devons toujours préciser aux gens de ne pas s'attendre à ce que Redux fasse tout. @gaearon le dit clairement tout le temps, mais malheureusement, les gens sont habitués aux frameworks qui font tout. Pourquoi devraient-ils être motivés pour apprendre quelque chose qui « ne fait pas grand-chose » ? Angular fait beaucoup plus que Redux. Pourquoi Redux ? La réponse est probablement évidente pour nous tous dans ce numéro. Mais est-ce clair pour les débutants ?

J'ai écrit un court article à ce sujet hier : Ne blâmez pas React ou Redux . Bien sûr, je peux me tromper sur tout ça.

Il existe un précédent pour avoir des couches d'abstraction au-dessus d'une bibliothèque avancée. Tout récemment, Tensorflow a introduit Keras en tant qu'abstraction au-dessus de l'API principale : http://www.fast.ai/2017/01/03/keras/.

L'utilisation de TensorFlow me donne l'impression que je ne suis pas assez intelligent pour utiliser TensorFlow ; alors que l'utilisation de Keras me donne l'impression que les réseaux de neurones sont plus faciles que je ne le pensais. C'est parce que l'API de TensorFlow est verbeuse et déroutante, et parce que Keras possède l'API la plus réfléchie et la plus expressive que j'aie jamais connue. J'étais trop gêné pour critiquer publiquement TensorFlow après mes premières interactions frustrantes avec lui. C'était si maladroit et contre nature, mais c'était sûrement mon échec.

J'ai l'impression que c'est une expérience similaire pour la plupart des débutants qui entrent dans Redux. Remplacez Tensorflow par Redux et Keras par Jumpstate . Redux est très puissant, mais la majorité des utilisateurs n'ont probablement pas besoin de tout le contrôle disponible. Plus que probablement, ils viennent d'Angular ou apprennent React + Redux lors d'un bootcamp ou en regardant divers tutoriels. Bien que Redux n'ait pas besoin d'être simplifié pour les nouveaux utilisateurs, ce n'est pas non plus un anti-modèle pour fournir une abstraction plus facile qui peut probablement couvrir 80% des cas d'utilisation potentiels.

Vous tous, si le redux était parfait comme ça, nous n'aurions pas cette conversation. Que le redux soit utile ou structurellement solide, les gens se sentent toujours « mal » lorsqu'ils l'apprennent pour la première fois. Ces sentiments sont valables.

Les personnes qui commentent dans ce fil sont toutes des experts en redux -- bien sûr, nous sommes satisfaits de la redux ; nous avons intériorisé sa philosophie et nous nous sentons à l'aise de faire nos propres abstractions pour gérer le « passe-partout ». Nous ne sommes pas le public que ce fil est destiné à servir. Nous devons avoir de l' empathie pour les utilisateurs qui viennent pour la première fois au redux, peut-être même pour la première fois à la programmation fonctionnelle.

Par exemple : voici une plainte que j'entends fréquemment à propos de redux (je ne pense pas qu'elle ait été mentionnée en amont) : il ne suffit pas d'utiliser simplement redux, vous avez également "besoin" d'utiliser react-redux, redux-thunk, redux-actions, etc. .

Avez-vous littéralement besoin d'utiliser tous ces autres packages pour utiliser redux ? Non.
La plupart des utilisateurs de redux finiront-ils par utiliser tout ou partie de ces packages supplémentaires ? Oui.

Le nombre de colis dans package.json important ? Non, pas vraiment.
Le nombre de paquets dans package.json affecte-t-il la façon dont les gens se sentent ? Absolument.

Maintenant, je pense qu'il est juste de croire que le redux lui-même devrait rester tel qu'il est, et qu'un autre package ( create-redux-app ou autre) devrait gérer leur assemblage. Mais nous avons un vrai problème de complexité entre nos mains et ce n'est pas suffisant pour dire aux utilisateurs de RTFM.

Que le redux soit utile ou structurellement solide, les gens se sentent toujours « mal » lorsqu'ils l'apprennent pour la première fois. Ces sentiments sont valables

Absolument. Mais tout le monde ne ressent pas ça. Certains le font. Gardez à l'esprit que vous n'entendrez jamais parler de personnes qui n'ont pas eu de problèmes. Vous ne voyez que ceux qui vous posent des questions, ou qui tapent stackoverflow/reactiflux. Parmi ceux qui ne le font jamais, certains ont aussi besoin d'aide mais ne savent pas comment la demander... et certains se débrouillent bien aussi, et vous ne voulez pas aggraver la situation pour eux... être celui qui vient sur les forums à la place et ce sera un gain net nul.

Redux n'est pas devenu populaire sans raison. Beaucoup de gens pensaient que c'était sacrément bien et l'ont recommandé à d'autres :)

Maintenant, je pense qu'il est juste de croire que le redux lui-même devrait rester tel qu'il est, et qu'un autre package (create-redux-app ou autre) devrait gérer leur assemblage.

J'ai aimé cette idée. Il serait possible de faire valoir que les passe-partout existants le résolvent déjà, mais React avait également beaucoup de passe-partout à l'époque où les gens se plaignaient d'être submergés d'outils lorsqu'ils essayaient d'entrer dans React. create-react-app était une excellente réponse à tout cela, car il a déjà éliminé de nombreuses étapes pour les débutants pour entrer dans React _itself_.

Mais c'est toujours passe-partout sous le capot. Donc, nous devons toujours encourager les gens à adhérer à l'écosystème et préciser que Redux lui-même ne fait pas grand-chose par conception . Il n'est pas possible de fuir l'écosystème si vous souhaitez utiliser React ou Redux.

Je ne pense pas que l'inclusion de packages tels que redux-thunk dans le noyau Redux soit la voie à suivre ici.

Juste pour plus de clarté, le genre d'idées que je lance ne concerne pas réellement l'inclusion de choses directement dans le noyau. Il s'agit de créer hypothétiquement une sorte de "configuration pré-construite" ou de "couche d'abstraction de facilité d'utilisation" qui serait un package distinct ou un outil CLI ou quelque chose du genre, plutôt create-react-app .

Je pense que je ferais mieux d'intervenir en tant qu'auteur de Jumpstate/Jumpsuit.

TL ; DR :
Redux est difficile à apprendre et à configurer/intégrer car il est de très bas niveau. La communauté pourrait bénéficier d'une API redux standardisée de niveau supérieur visant le cas d'utilisation à 90 % pour faciliter la courbe d'apprentissage et même fonctionner comme une solution pour des projets plus simples. Jumpstate essaie de résoudre ce problème, mais ce n'est pas une solution à long terme. Nous devons commencer à proposer des idées possibles (réel ou méta-code) sur l'apparence de cette API.

Redux est très difficile à apprendre dès le départ et, très souvent, tout aussi difficile à intégrer avec de nouveaux concepts comme la logique asynchrone, les effets secondaires, les middleware personnalisés, etc. était très nouveau dans l'écosystème React.

Quelques jours seulement après avoir appris à réagir, on m'a immédiatement recommandé d'apprendre le redux. Cette recommandation provenait à la fois de développeurs très expérimentés et novices qui avaient fait (ou faisaient) la même chose. Il était salué comme la solution de facto pour tout ce qui s'étendait au-delà de setState (gardons cependant la porte setState en dehors de cela 😉 ). Tout cela pour une bonne raison, car le redux est incroyable.

J'ai inévitablement atteint la courbe d'apprentissage et lorsque j'ai demandé de l'aide, j'ai immédiatement réalisé que l'approche marketing et documentée pour Redux prenait le ton de " Redux est difficile, les concepts sont de bas niveau, l'API est verrouillée et vous avez juste besoin de passer en revue ce."

C'est donc ce que j'ai fait avec tous mes pairs. Nous l'avons alimenté parce que c'était ce à quoi nous avons été éduqués. Cependant, tout au long de ce voyage, j'ai osé créer très tôt une couche d'abstraction qui masquerait temporairement et délibérément une partie de la complexité et des fonctionnalités avancées que le redux avait à offrir.

Je n'avais pas besoin de créateurs d'actions personnalisés, je ne voulais pas m'inquiéter du mappage des actions et des répartiteurs sur les composants et, comme beaucoup d'autres, j'ai opté pour une disposition de réduction moins détaillée à la place d'une instruction switch.

Cela a fonctionné à merveille. Si bien, en fait, que cela a accéléré le processus d'apprentissage du redux pour le reste de mes pairs et d'autres développeurs qui étaient également aux prises avec la courbe d'apprentissage.

Nous l'avons conçu de manière à ce que le redux avancé ou « idiomatique » puisse toujours être utilisé lorsque nous en avons besoin, mais nous l'avons vraiment conçu pour notre cas d'utilisation à 90 %.

Je ne dis en aucun cas que jumpstate couvre toutes les bases, en fait, il y a encore tellement de choses qui doivent changer pour que jumpstate se comporte "idiomatiquement" (créateurs d'actions personnalisables, suppression des importations d'actions globales... il y en a beaucoup) , mais cela a certainement aidé de nombreuses personnes à apprendre les bases et leur a permis de comprendre comment fonctionne le redux à un niveau très simple. Tout le temps, je reçois un message dans l'organisation Jumpstate slack indiquant que jumpstate a aidé quelqu'un à apprendre le redux.

Que ces personnes utilisent encore jumpstate aujourd'hui ou non n'a pas beaucoup d'importance (mais beaucoup de gens l'utilisent encore en production aujourd'hui). Ce qui comptait, c'était l'expérience qu'ils avaient et la rapidité avec laquelle ils ont pu devenir productifs dans l'écosystème du redux.

Quelques autres idées qui me viennent à l'esprit pour cette discussion :

• proposez des méta-exemples de ce à quoi pourrait ressembler un redux simplifié, jetez-y un coup d'œil !
• discuter des exigences et décider d'un standard pour les middlewars redux souvent dupliquées et extrêmement opiniâtres. Nous pourrions commencer par la gestion asynchrone. Cela pourrait résoudre tant de fragmentation dans la communauté redux et aider les efforts de chacun à faire une différence pour la survie à long terme et l'utilisation de redux.

Dans quelle mesure cela pourrait-il être résolu avec des documents améliorés d'une manière ou d'une autre ?

Beaucoup. En ce qui concerne la documentation Redux, j'ai l'impression qu'à bien des égards, c'est pire que la documentation d'AngularJS 1 car, comme celle d'AngularJS, elle est inutilement détaillée mais contrairement à celle d'AngularJS, elle échoue au principe "afficher, ne pas dire".

Les documents de Redux préfèrent les extraits de code plutôt que la démonstration réelle du code, ce qui signifie qu'il y a trop de moments "voici un ensemble de code; nous ne vous dirons pas comment il se connecte, mais croyez-nous que cela fonctionne". Le manque de capacité à exécuter des exemples dans un navigateur signifie que l'utilisateur est obligé de faire confiance à son propre instinct pour dire que ce qu'il fait localement fonctionne et si quelque chose ne fonctionne pas, il se débrouille tout seul. Même la simple application Todo List, je pense que ce n'est pas le meilleur exemple "hello world" de Redux - cela pourrait être beaucoup plus simple.

Des diagrammes seraient certainement utiles ici. Par exemple, j'aime celui de @sunjay ; un qui pourrait même être meilleur est d'en concevoir un pour l'exemple de la liste de tâches lui-même - comment les fichiers sont-ils connectés, etc. à partir d'une vue de haut niveau. Les images sont presque toujours meilleures pour transmettre un texte long et peuvent aider à réduire la verbosité des documents. Les images aideraient également les débutants à rester concentrés et à mieux comprendre Redux dans son ensemble.

Mes deux cents : s'il vous plaît ne changez pas de noyau. Son éclat réside dans sa simplicité. À ce stade, y ajouter quelque chose enlèverait probablement quelque chose à l'ensemble.

La convivialité et l'abstraction supplémentaire peuvent se produire dans l'espace utilisateur. Je n'ai pas l'impression qu'il doit y avoir un moyen officiel ou idiomatique de l'utiliser non plus. C'est un conteneur d'état prévisible, c'est tout !

Il peut tenir tout seul, qu'il en soit ainsi ❤️

Cela dit, bien sûr, emballez-le comme vous le souhaitez en créant plus de bibliothèques d'opinion par-dessus. C'est ce que je fais aussi, mais ne changeons pas de noyau, s'il te plaît.

@HenrikJoreteg ,

Beaucoup. En ce qui concerne la documentation Redux, j'ai l'impression qu'à bien des égards, c'est pire que la documentation d'AngularJS 1 car, comme celle d'AngularJS, elle est inutilement détaillée mais contrairement à celle d'AngularJS, elle échoue au principe "afficher, ne pas dire".

C'est très vrai. Une chose quand Redux était nouveau, c'est que la documentation était clairsemée, mais les bases étaient là. Beaucoup de gens l'ont adopté parce qu'il était "si simple". Mais les ressources en ligne essaient maintenant de montrer les « techniques du monde réel », qui ne sont souvent que « mon middleware préféré » et « mes outils de réduction passe-partout préférés ». Les gens sont dépassés.

Il y a quelque chose à dire sur "moins c'est plus"

@Phoenixmatrix , @Sylphony : alors, à quoi ressemblerait une refonte potentielle de la doc ?

Personnellement, pour le combiner avec mes suggestions ci-dessus d'avoir un "starter-store", je le diviserais en deux (pas 2 sites/documents différents, mais 2 sections différentes).

L'"architecture Redux", qui aurait beaucoup de dessins simples et mignons, explique les actions et les réducteurs, introduit le réac-redux et peut-être les thunks, utilise le "starter store" pour limiter tout type de configuration initiale et montre à quel point cela peut être facile consiste à créer une application simple qui effectue quelques requêtes ajax et affiche des éléments à l'écran.

Tout le reste peut aller dans une section « explorer » avec les concepts les plus avancés. Même alors, je déchirerais probablement beaucoup de choses. Quelqu'un m'a fait remarquer aujourd'hui qu'il existe une section sur la création de plusieurs magasins dans une application. C'est bon à savoir, mais les utilisations sont vraiment avancées. Je ne pense pas qu'un nouveau venu ait besoin de tomber dessus sans regarder.

De meilleurs documents sont toujours une excellente idée, mais je ne pense pas que cela résolve le problème principal ici. Les bibliothèques d'abstraction sont écrites et adoptées en raison de la simplicité et de la verbosité de l'API Redux. Ces mêmes bibliothèques fragmentent la communauté Redux car elles sont évidemment nécessaires à un niveau ou à un autre. C'est frustrant quand ces mêmes auteurs qui essaient activement de contribuer à l'écosystème sont rabaissés et rejetés publiquement parce qu'ils "ne comprennent pas Redux". Si la communauté peut à la place créer une abstraction plus simple, ne faisant pas partie du noyau de React, mais « bénie » dans une certaine mesure, alors tout le monde y gagne. Les utilisateurs inconditionnels continuent d'utiliser Redux tel quel, d'autres personnes peuvent utiliser une abstraction avec une API plus simple/moins verbeuse.

@derekperkins Comment parvenir à un consensus sur une bibliothèque « bénie » ? Comment décidons-nous de ce qu'il contient et qui va travailler dessus ?

Je suis tout à fait pour quelque chose comme ça, mais comment éviter de simplement créer une autre bibliothèque que seules certaines personnes utilisent et ainsi fragmenter encore plus l'écosystème.

xkcd pertinent : https://xkcd.com/927/

Oui, le noyau de redux et react-redux sont aussi proches que possible d'un consensus. Même redux-thunk et redux-actions sont assez limites, car même à ce niveau, la majorité des gens ont des besoins différents.

Réduire le passe-partout dans Redux est une question de "Je n'ai pas besoindonc je vais l'abstraire. Mais même pour les nouveaux arrivants, "cette partie" varie considérablement.

Bon sang, nous avons beaucoup (plusieurs dizaines) d'applications de redux au travail et il est difficile de créer une pile de réduction passe-partout commune car différentes applications ont des exigences différentes. C'est facile lorsque vous avez une seule application ou plusieurs avec les mêmes exigences. Même les plus petits diffèrent un peu.

L'idée ici n'est pas de mettre en place une boîte à outils qui résout tous les problèmes pour tout le monde. En utilisant CRA comme exemple : il existe des tonnes de façons de configurer Babel, Webpack et ESLint. Ce que fait CRA, c'est d'offrir un moyen unique et avisé de les faire tous fonctionner sans aucun problème de la part de l'utilisateur, et il sélectionne délibérément un certain nombre de paramètres qui améliorent les choses pour les apprenants. Il permet ensuite à l'utilisateur de prendre le contrôle de la configuration _s'il le souhaite_.

Il n'essaie pas non plus de résoudre tous les cas d'utilisation. CRA n'essaie pas de s'attaquer au fractionnement de code avancé, aux points d'entrée multiples, au SSR ou à des choses comme ça. Les documents de l'ARC _do_ pointent vers d'autres outils et options qui peuvent offrir plus de configurabilité et mieux fonctionner pour certains cas d'utilisation.

C'est une excellente façon de le dire. Quelque chose pour se lever et courir vite qui
implique uniquement l'installation de redux et cette couche de configuration hypothétique ? Cette
serait génial.

Une autre idée que j'ai eue serait un indicateur que vous pourriez définir en mode dev qui pourrait
surveiller et exposer les opportunités d'apprentissage incrémentielles pour l'utilisateur. Dans
de cette façon, la couche d'abstraction pourrait servir d'outil pédagogique interactif.
Le lundi 20 mars 2017 à 16h14 Mark Erikson [email protected]
a écrit:

L'idée ici n'est pas de mettre en place une boîte à outils qui résout tous les problèmes
pour tout le monde. En utilisant CRA comme exemple : il existe des tonnes de façons de configurer
Babel et Webpack et ESLint. Ce que fait l'ARC, c'est offrir un
moyen de les faire tous fonctionner sans aucun problème de la part de l'utilisateur, et il
choisit délibérément un certain nombre de paramètres qui améliorent les choses pour
apprenants. Il permet ensuite à l'utilisateur de prendre le contrôle de la configuration siils veulent .

Il n'essaie pas non plus de résoudre tous les cas d'utilisation. L'ARC n'essaie pas de
s'attaquer au fractionnement de code avancé, aux points d'entrée multiples, au SSR ou à des choses comme
cette. L'ARC docs ne pointent vers d' autres outils et options qui peuvent offrir
plus de configurabilité et fonctionnent mieux pour certains cas d'utilisation.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/reactjs/redux/issues/2295#issuecomment-287914805 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AFUmCactFzsw7etmGGP8MFK6kfNaOzTJks5rnvorgaJpZM4MhnVF
.

@sunjay Je savais quel lien xkcd c'était sans même avoir à cliquer. :)

Je suis d'accord avec @markerikson. Il ne s'agit pas d'essayer de gérer tous les cas extrêmes pour chaque personne. Il s'agit d'une déclaration opiniâtre des principaux développeurs de Redux disant: "c'est un bon moyen de faire fonctionner les choses". Il existe des valeurs par défaut raisonnables qui peuvent être remplacées si nécessaire, mais je parierais que les valeurs par défaut fonctionneront pour 80% des développeurs.

Cela peut ou non être écrit sur le noyau Redux. Je pense toujours qu'il y a une place pour quelque chose comme Jumpstate qui fait plus qu'accélérer la courbe d'apprentissage.

La courbe d'apprentissage Redux peut être raide, mais une fois que vous avez compris les concepts, le besoin de couches d'abstraction disparaît souvent

Je pense que c'est vrai dans une certaine mesure, mais cela ne signifie pas nécessairement que vous voulez toujours éliminer la couche d'abstraction. Même si j'ai écrit C dans le passé et que je comprends l'allocation de mémoire, je préfère de loin écrire en Go où le ramasse-miettes est géré pour moi. Selon mon exemple Tensorflow plus tôt, il serait plus performant d'écrire sur les API de niveau inférieur, mais il y a aussi beaucoup à dire sur la facilité d'utilisation de l'abstraction Python keras. De même, pour Redux vs Jumpstate (ou toute autre abstraction provenant de ce problème), ce n'est pas que le passe-partout n'est pas nécessairement difficile à écrire, c'est juste encombrant pour la plupart des cas d'utilisation qui n'ont pas besoin de toute la flexibilité de Redux brut.

Si ça ne tenait qu'à moi, j'aimerais voir ça :

• Un sous-ensemble convivial Flow/TypeScript qui est plus facile à saisir que vanilla Redux.
• Ne pas trop insister sur les constantes (rendez simplement l'utilisation de littéraux de chaîne plus sûre).
• Maintenir l'indépendance de React ou d'autres bibliothèques de vues mais faciliter l'utilisation des liaisons existantes (par exemple, fournir des implémentations mapStateToProps ).
• Préservation des principes Redux (actions sérialisables, voyage dans le temps et rechargement à chaud devraient fonctionner, le journal des actions devrait avoir un sens).
• Prise en charge du fractionnement de code d'une manière plus simple, prête à l'emploi.
• Encourager la colocation des réducteurs avec les sélecteurs et les rendre moins difficiles à écrire ensemble (pensez à des ensembles réducteurs-sélecteurs faciles à écrire et à composer).
• Au lieu de colocaliser les créateurs d'action avec les réducteurs, se débarrasser complètement des créateurs d'action et rendre le mappage plusieurs-à-plusieurs des actions aux réducteurs naturel (plutôt que de s'en détourner comme le font la plupart des bibliothèques).
• Faire des valeurs par défaut de performances raisonnables afin que la mémorisation via Reselect "fonctionne" pour les cas d'utilisation courants sans que les utilisateurs n'écrivent ce code.
• Contenant des assistants intégrés pour l'indexation, la normalisation, les collections et les mises à jour optimistes.
• Avoir un support de flux asynchrone testable intégré.

En plus du noyau, bien sûr, même s'il est bon de le marquer comme un élément officiel de Redux.
Aussi, je n'écrirai pas ceci. Mais tu peux.

Pour moi, il y a quelques mois quand j'ai appris redux , j'ai lu la doc mais je ne comprends pas très bien, donc j'ai passé 2 jours à lire le code src , puis chaque description sur api de le doc devient clair .

Et puis, la réflexion sur les chapitres « conception de l'état », « division du réducteur », « conception du middleware », « la solution asynchrone » ...... devient claire aussi avec le développement du projet les mois prochains.

Donc, je pense que lire le code src est la meilleure étape pour apprendre redux , et seulement après cela, vous pouvez comprendre et explorer l'environnement de redux plus facilement.

prise en charge asynchrone par défaut.

Je veux dire pas besoin d'utiliser un autre plugin tel que redux-thunk, redux-saga .

prise en charge asynchrone par défaut

C'est le cas, c'est juste que les gens le regardent pendant 0,5 seconde avant de chercher quelque chose de mieux. Rien ne vous empêche d'appeler des API à l'intérieur de vos composants, puis d'appeler le dispatch dans les résolutions de rappel/promesse. C'est juste que les gens veulent l'extérioriser tout de suite (moi inclus). Mais vous pouvez très bien faire async sans aucun middleware.

Le commentaire de @gaearon est parfait, en ce sens qu'il met en évidence à quel point il y a un large balayage. J'aime et j'apprécie totalement la précision, l'élégance et la puissance du Redux 2.0 qu'il propose, et pourtant, presque aucune de ces améliorations ne me concerne !

Je trouve ça vraiment fascinant.

Ma propre bibliothèque d' abstraction Redux fait presque entièrement le contraire. Je trouve une immense valeur dans les actions à réducteur unique, dans le regroupement des fonctions de réducteur atomique avec leurs codes d'action et leurs sélecteurs, en supprimant entièrement les chaînes en faveur des clés d'objet. C'est ma propre solution à 90 %, plus semblable à l'attitude de l'ARC qu'autre chose.

Le point intéressant est en grande partie : quels problèmes essayons-nous de résoudre ? Il existe de nombreux problèmes, avec plusieurs espaces de solutions différents disponibles. Si Dan construisait Redux 2.0 comme il l'a décrit, je reconstruirais aussi ma propre bibliothèque d'abstraction par-dessus !

@jbellsey Redux est excellent pour fournir des actions et un état à l'application dans le monde - mais dans une portée définie - vous pouvez avoir des instances infinies de magasin redux mais vous pouvez les combiner. Fondamentalement, cela est utile pour les bibliothèques. Si vous voyez une bibliothèque parler de redux à l'intérieur, vous pouvez bénéficier de...

quels problèmes essayons-nous de résoudre?

État global de l'application. R eliable un E sthetics D U elivered nified e X tensible: heart:

Personne ne veut de global. Mais tout le monde en a besoin :tm:

S'il vous plaît, gardez le redux simple tel qu'il est maintenant. C'est un modèle. Les livres de cuisine surgiront toujours vers :100:

@markerikson Serait-il une bonne idée de commencer un document/une feuille de calcul pour organiser ces pensées ? Il y a déjà eu des idées incroyables et cela ne fait que 48h

Pour moi, je ne recommanderais pas aux gens d'utiliser des thunks ou des sagas. Au lieu de cela, apprenez les techniques d'injection de dépendances en JavaScript.

Redux devient plus facile une fois que je le traite comme une simple base de données :

• Je dis à Redux l'état initial et comment une action (événement) affecte l'état de l'application. (Comme le schéma de base de données et les procédures stockées.)
• Ensuite, Redux s'occupe de le gérer et de notifier les auditeurs, et fournit des moyens d'inspecter et de déboguer l'état.

Pour moi, c'est tout ce que Redux est pour moi (je ne m'attendrais pas à ce qu'une base de données fasse un appel HTTP). Pour les E/S et les trucs asynchrones, je l'exécute en dehors de Redux. Cela garde mon magasin Redux prévisible. Le type de signature est toujours store.dispatch(actionObject) . Aucune fonction de répartition et aucune signification cachée à l'intérieur de l'action (par exemple, la répartition d'une action ne fera pas d'appel d'API).

@tannerlinsley : Ouais, vas-y.

Un inconvénient pour moi de commencer cette discussion : j'ai déjà une tonne de choses sur lesquelles je dois travailler et écrire. Une grande partie est auto-imposée, mais cela signifie que je n'ai pas assez de temps pour travailler sur certains des sujets liés à Redux que j'aimerais étudier, encore moins pour aborder des choses comme une refonte majeure de la documentation ou créer une nouvelle boîte à outils à partir de rayure.

Je veux absolument être impliqué dans ces efforts possibles, mais il va falloir que d'autres personnes se joignent et travaillent ensemble. (Célèbres derniers mots de chaque mainteneur d'OSS... :))

Redux devient plus facile une fois que je le traite comme une simple base de données

C'est ce que je recommande !

• Gardez votre magasin normalisé
• Vous pouvez préparer des données, comme des vues. Faites cela par des réducteurs dédiés - vous n'avez alors pas besoin de reselect . Envisager.
• Les actions ne doivent pas déclencher d'autres actions - cela peut sembler facile. Mais c'est difficile si vous avez des crochets componentDidMount . Je ne sais pas comment résoudre cela. Il n'est pas toujours facile de déplacer cela dans la hiérarchie

FWIW, j'utilise Redux avec D3.js (sans React) et ça se passe plutôt bien. Quelques exemples de ceci sont répertoriés dans d3-component .

La chose qui me manque le plus dans les liaisons React Redux est connect . Le point qui m'intéresserait le plus dans l'aperçu/la vision ci-dessus de @gaearon est de "fournir des mapStateToProps ".

Vous pouvez préparer des données, comme des vues. Faites cela par des réducteurs dédiés - vous n'avez alors pas besoin de resélectionner. Envisager.

Ouais, c'est un peu ce que Twitter fait dans son magasin, du moins je pense - ils ont entities branche timeline dire

Et c'est ce que je recherche dans les prochains refactors, car la resélection de listes très dynamiques n'est... pas trop performante ;) être assez encombrant à long terme car vous devez souvent vous souvenir d'environ 2 endroits (ou plus).

@stefensuhat lorsque j'ai essayé d'implémenter Redux par moi-même, j'ai utilisé une boucle Promise pour rendre possibles les actions asynchrones. Vous pouvez le vérifier sur https://github.com/iddan/delux

@gaearon totalement d'accord avec ta liste ! Nous avons travaillé sur un redux passe-partout suivant 90% de la liste de l'organisation dans laquelle je travaille (également en suivant les principes des canards). C'est une version anticipée pour le moment, pas prête à être publiée.

J'aimerais bien contribuer à cette bonne idée !

@markerikson @tannerlinsley

En ce qui concerne l'organisation de ces idées, je suggère qu'après avoir créé la feuille de calcul, vous créez des problèmes Github dans les dépôts appropriés pour suivre le développement. Vous devriez ensuite commenter ici avec une liste de ces problèmes.

Cela ne garantit pas que quoi que ce soit en particulier sera livré avec le redux, mais cela donne aux personnes intéressées par cette chose en particulier l'opportunité de suivre la discussion et de travailler ensemble pour y arriver.

La tâche de concrétiser ces suggestions incombe à tous ceux qui sont intéressés par chaque nouvelle fonctionnalité ou approche. Bien que Mark ait lancé la discussion, je suis sûr que personne ne s'attend à ce qu'il aille tout mettre en œuvre. :)

Oui, la liste de @gaearon est idéale, mais comme certaines personnes l'ont déjà mentionné, c'est beaucoup de choses. Quiconque tentera de s'y attaquer directement sera confronté à l'oubli du vélo. J'aimerais que cela se produise malgré tout, mais je pense que les petites pièces devraient être attaquées à la fois, plutôt que de construire une couche complète par-dessus (en poussant encore une fois mon exemple d'un magasin de démarrage préconfiguré ;) )

Cela dit, quand/si quelqu'un essaie d'attaquer toute cette liste, gardez également à l'esprit quels autres outils et frameworks existent en dehors de Redux, et même en dehors de React. React/Redux présente un ensemble intéressant d'avantages par rapport à vanilla Flux, à MobX, à VueJS et à son écosystème, à Angular. Quoi que fasse la communauté, elle souhaite probablement se concentrer sur certains de ces avantages (dont certains font partie de la liste de

Exemple que j'invente : il peut être tentant de créer un module qui vous permet de créer une fonction qui met automatiquement à jour un réducteur généré automatiquement. Mais une fois que vous avez fait cela, vous avez répliqué MobX, donc ce n'est pas très utile à faire.

@Phoenixmatrix oui, ce que je veux dire, c'est que redux a un middleware par défaut, nous n'avons donc pas besoin d'en utiliser un externe. ??

Je ne vois vraiment rien de mal avec l'implémentation actuelle de Redux. Le passe-partout existe mais ce n'est vraiment pas grave si vous avez un système de type.

Un problème majeur pour moi est que les gens ne semblent pas comprendre que nous construisons des applications frontales qui sont bien plus complexes qu'elles ne l'étaient il y a quelques années. Si nous construisons des applications plus grosses, plus complexes, avec de grandes équipes, il est normal pour moi que la difficulté augmente significativement, que de nouveaux schémas émergent, pourtant les gens rejettent cette difficulté.

Je ne dis pas que nous ne devrions pas essayer de simplifier les choses ou de réduire le passe-partout, mais que les gens ne devraient pas commencer à utiliser Redux et se plaindre du passe-partout impliqué sans comprendre les compromis faits et voir la situation dans son ensemble.

Lorsque Redux a été créé, beaucoup de gens (moi y compris) ont essayé de construire cette chose, et @gaearon a obtenu la meilleure implémentation et a fait un très bon travail sur l'outillage/la démo. Il (et aussi Flux) a obtenu beaucoup de traction au départ, non seulement à cause du voyage dans le temps, mais aussi parce que le concept n'était pas nouveau pour beaucoup de gens et semblait immédiatement naturel.

Les gens voient Redux comme un nouveau jouet brillant (cela semble finir par être pas si facile dans la pratique). Pourtant, rien dans Redux n'est vraiment nouveau, sauf le fait que quelqu'un a porté ces concepts d'une manière élégante vers le frontend. Les modèles de Redux et son écosystème sont déjà utilisés dans les systèmes distribués, les applications backend événementielles, la conception axée sur le domaine, et les personnes ayant une formation dans ces domaines comprendront très facilement Redux.

Malheureusement, les gens veulent sauter des étapes et utiliser Redux sans rien savoir des modèles plus généraux impliqués. Personnellement, je recommanderais à tous ceux qui souhaitent créer quelque chose de sérieux dans Redux d'avoir un minimum d'expérience dans les systèmes distribués. Cela peut sembler étrange, mais je pense qu'avoir ce genre d'expérience peut vous donner un avantage très sérieux en ce moment et dans les années à venir.

Que construisons-nous exactement lorsque nous construisons une application frontend ?

• Nous construisons un membre d'un système distribué
• Ce membre ne détient qu'un sous-ensemble des données du système plus général
• Ce membre a des capacités assez limitées (stockage, bande passante, stabilité du réseau...)

Donc, nous essayons de construire quelque chose de très complexe. Nous avons des contraintes plus difficiles à gérer que les développeurs de bases de données, mais nous voulons que ce soit plus simple, sans réutiliser les connaissances antérieures de personnes qui ont vraiment réfléchi à ces problèmes pendant de nombreuses années. Ne pensez-vous pas que les gens ont déjà réfléchi à la manière de structurer l'état à l'intérieur d'une base de données ? comment l'interroger ?

Je ne dis pas que nous ne devons pas être pragmatiques, expédier des applications aujourd'hui et faire des erreurs avec nos connaissances actuelles, mais plutôt comprendre et reconnaître que ce que nous construisons n'est plus simple et nécessite des connaissances supplémentaires. Redux peut être un bon moyen d'obtenir ces connaissances, et vous pouvez l'utiliser de manière pragmatique au début, mais ne sous-estimez pas à quel point le développement frontend vous mettra mal à l'aise dans les années à venir.

Malheureusement, les gens veulent sauter des étapes et utiliser Redux sans rien savoir des modèles plus généraux impliqués.

Pour le meilleur ou pour le pire, Redux a essentiellement gagné la bataille pour la gestion de l'état React. Avec cela vient la capacité de façonner l'écosystème. Il y aura toujours des développeurs qui voudront juste quelque chose qui fonctionne, et il existe de nombreuses applications plus simples où c'est tout ce qui est nécessaire. Soit les gens continueront à utiliser d'autres couches d'abstraction, soit ils peuvent être initiés aux modèles généraux corrects via une simple bibliothèque.

Personnellement, je recommanderais à tous ceux qui souhaitent créer quelque chose de sérieux dans Redux d'avoir un minimum d'expérience dans les systèmes distribués. Cela peut sembler étrange, mais je pense qu'avoir ce genre d'expérience peut vous donner un avantage très sérieux en ce moment et dans les années à venir.

C'est le nœud du problème. Redux tel quel fonctionne très bien pour les personnes qui le comprennent. Ce n'est pas nécessairement une mauvaise chose cependant de le simplifier. La plupart des gens n'écrivent plus de code assembleur, même si le comprendre vous aide généralement à écrire un meilleur code. Ce n'est tout simplement pas par là que la plupart des gens commencent.

Beaucoup plus de bons commentaires tout autour. Il y a des tonnes d'idées ici que nous pourrions et devrions explorer davantage.

Voyons si nous pouvons commencer à proposer des idées potentiellement exploitables. Je vais commencer par lancer un petit concept de base :

Créez un nouveau package appelé, je ne sais pas, redux-starter ou quelque chose. Ce package peut dépendre de redux-actions , redux-thunk et redux-logger , et peut-être d'un middleware basé sur des promesses. Il fournirait une fonction avec la signature function createReduxStore({reducers, middleware}) {} (basée sur le commentaire de @Phoenixmatrix plus tôt ). Peut-être même pas la peine d'accepter le middleware ?

La fonction createReduxStore() se chargerait de gérer applyMiddleware et de configurer le rechargement à chaud pour le réducteur de racine, ainsi que de configurer l'extension Redux DevTools. Si aucun middleware n'est fourni, il configurera ceux inclus par défaut. Cela peut ressembler au code de configuration du service de magasin dans ember-redux ou à la fonction configureStore dans mon exemple d'application "Project Mini-Mek" .

Cela réduirait au moins la quantité de configuration nécessaire pour démarrer et fournirait un ensemble modeste de fonctionnalités utiles.

Ouais, j'aime ça (enfin, je n'aime pas les actions de redux et les middlewares basés sur des promesses pour les nouveaux utilisateurs, mais je vous laisse vous amuser avec le bikeshedding sur celui-là). Je ne prendrais pas la peine d'accepter les middlewares, il suffit de créerStarterStore (réducteur).

Peut-être même remplacer combineReducer, vous pouvez donc simplement faire :

const store = createStarterStore({
   foo,
   bar,
   baz
});

où foo bar baz sont des réducteurs.

Drat. Je viens de réaliser qu'"une fonction de bibliothèque qui configure HMR pour le réducteur racine" ne fonctionnera probablement pas, car même si nous permettions à l'utilisateur de transmettre le chemin d'accès à son fichier de réducteur racine, l'un ou les deux module.hot.accept() API require(path) veulent des chemins analysables de manière statique au moment de la construction et non des variables. (Je pense... Je peux me tromper.) Oh, eh bien.

Mais oui, createStarterStore() pourrait accepter soit le réducteur racine, soit l'objet slices.

Personnellement, je recommanderais à tous ceux qui souhaitent créer quelque chose de sérieux dans Redux d'avoir un minimum d'expérience dans les systèmes distribués. Cela peut sembler étrange, mais je pense qu'avoir ce genre d'expérience peut vous donner un avantage très sérieux en ce moment et dans les années à venir.

@slorber je suis d'accord avec toi sur ce point.

Malheureusement, les gens veulent sauter des étapes et utiliser Redux sans rien savoir des modèles plus généraux impliqués.

Mais pas vraiment sur celui-ci. Certaines personnes connaissent les modèles impliqués dans Redux, et c'est précisément pourquoi ils ont choisi de l'utiliser. Vouloir utiliser quelque chose de simple (ou du moins de plus simple) ne signifie pas nécessairement que l'utilisateur n'est pas capable d'utiliser une implémentation plus difficile. Cela économise simplement du temps et des efforts.

À l'endroit où je travaille, nous utilisons Redux depuis un an maintenant, et nous nous sommes retrouvés à copier/coller le même code (en le modifiant seulement un peu) pour ajouter de nouvelles ressources au magasin, c'est pourquoi à un moment donné nous nous sommes sentis la nécessité d'implémenter une couche au-dessus de Redux, pour faire abstraction de ce passe-partout redondant.
À mon avis, cette idée ne simplifie pas seulement l'utilisation de Redux, mais réduit également le passe-partout pour les parties les plus courantes (de la même manière, react-redux réduit le passe-partout lors de l'utilisation de Redux avec React).

Débat très intéressant. Mes deux cents en tant qu'utilisateur redux depuis les premiers jours :

Au début, si je me souviens bien, redux était davantage considéré comme un protocole ou un ensemble de conventions raisonnables qu'un cadre pour créer des applications. Cette austérité explique en partie pourquoi le redux peut être écrasant pour les nouvelles personnes et fastidieux à mettre à l'échelle sans faire rouler vos propres abstractions. Mais la façon simple dont il a réussi à surmonter le désordre de la gestion de l'état en 2015 est également une raison pour laquelle il a décollé, et le minimalisme a permis à des frameworks étonnants comme Apollo de se greffer sur le travail effectué pour différents projets (en particulier les outils de développement) et de donner une manière familière de "descendre à un niveau inférieur" dans la gestion de l'État en cas de besoin.

Je pense qu'il est clair qu'en tant que redux de bibliothèque "de bas niveau" a été un énorme succès, et en tant que cadre riche en fonctionnalités pour la création d'applications, ce n'est pas encore tout à fait là. Une chose à laquelle il faut faire attention est qu'au fur et à mesure que le redux évolue, il ne rompt pas son rôle de "protocole" standard de l'industrie pour des projets comme Apollo.

À cette fin, le redux actuel peut peut-être devenir un package comme redux-core , et redux lui-même élève le niveau d'abstraction pour donner un moyen recommandé de créer des applications. Bien sûr, il peut y avoir un certain nombre d'alternatives de niveau supérieur à ce redux (comme Apollo, ou quelque chose utilisant des sagas ?) en utilisant redux-core...

Reformuler les choses pour clarifier et mettre l'accent :

Tout travail sur ce fil n'inclura pas de modifications majeures à la bibliothèque Redux existante :) Une refonte de la documentation est totalement possible, et il pourrait y avoir quelques petites modifications, mais le package redux existant resterait tel quel.

Quelque chose comme le package redux-starter je viens de décrire, ou l'approche "framework"-y que Dan a décrite, serait un nouveau package qui dépend de redux .

Je vote que nous créons le package comme @markerikson l'a suggéré. Une fois que nous avons une base de code, nous pouvons commencer à nous battre autour de l'API, des extraits de code et des idées plus approfondies. Nous aurions alors un endroit pour créer des problèmes pour des fonctionnalités spécifiques.

Vous pouvez utiliser Delux en entrée (jk)

En tant que grand utilisateur de Jumpstate de @tannerlinsley (et maintenant l'un des responsables), je suis incroyablement excité à ce sujet. Mes raisons d'utiliser Jumpstate sont décrites très succinctement dans le message original de

Longue façon de dire : ça a l'air génial, je suis dedans, je ne sais pas combien je peux contribuer (je vais essayer) mais vous avez certainement une pom-pom girl.

J'ai maintenant utilisé Jumpstate pour enseigner Redux à plusieurs reprises et je peux dire avec confiance que cela a considérablement raccourci la courbe d'apprentissage. Je pense à Redux comme HTTP et Jumpstate comme fetch. J'adore Redux et j'ai écrit des choses (ridiculement) compliquées avec, mais je sais aussi que 90% de cas sont plus que suffisants pour enseigner la plupart des choses.

Quand on y pense, c'est un endroit formidable. L'une des principales plaintes concernant le développement frontal et le javascript en général est "le manque de bibliothèques standard". Le fait est que c'est une chose très nouvelle (TM) , pouvoir développer des applications complètes dans le navigateur. La pression monte enfin pour avoir besoin de bibliothèques standards. Voilà où nous en sommes maintenant.

Re: Courbe d'apprentissage, opiniâtreté et abstraction :

Ajax semble être un domaine où les nouveaux apprenants restent bloqués, qu'ils apprennent à utiliser des thunks, des sagas ou des épopées. Un domaine où ils ne semblent pas avoir beaucoup de difficultés est la création d'actions - car ce ne sont que de vieux objets Javascript, et nous avons la clarté supplémentaire fournie par la spécification Flux Standard Actions. Cette réflexion m'a amené à la question - Pourquoi ne pas développer une action Flux Standard Ajax ?

Par exemple

function fetchPosts(page) {
  return {
    type: 'FETCH_POSTS_REQUEST',
    // Ajax request setup
    ajax: {
      url: `/api/posts`,
      method: 'GET',
      data: { page },

      // Optional ajax meta attributes
      meta: {
        // Amount of time to debounce the execution of the request
        debounce: 400,
        // Amount of times to retry the request on failure
        retry: 2,
        // Amount of time before timing out
        timeout: 10000,  
        // The action type that cancels the request
        cancelType: 'CANCEL_FETCH_POSTS',
        // Strategy when multiple FETCH_POSTS_REQUESTs are in flight
        resolve: 'LATEST'
      }
    }
  };  
}

L'action ajax serait gérée par un middleware (qui réagirait à la touche ajax dans l'action).

J'ai essayé de penser aux raisons pour lesquelles cette approche serait une mauvaise idée, mais je n'ai pas encore pensé à des briseurs d'accord.
Quelques avantages à mon avis:

• une diminution spectaculaire du nombre d'actions asynchrones requises dans votre application moyenne (car les actions asynchrones liées à ajax disparaîtraient)
• facile à comprendre car nous ne traitons qu'avec de vieux objets javascript simples
• c'est déclaratif, les détails de mise en œuvre ne sont pas importants
• différentes implémentations pourraient être intégrées/sorties sans casse
• c'est un Redux idiomatique (le journal des actions a toujours du sens, sérialisable, etc.)

Je peux entendre certaines personnes invoquer l'argument de la séparation des préoccupations, mais je dirais que c'est une extension naturelle de ce que font déjà nos actions de demande ajax. Actuellement, ils mettent en place une action avec un contexte assez clair, 'FETCH_POSTS_REQUEST' , mais avec trop peu de contexte pour faire abstraction de l'implémentation de la requête ajax. Laissant peu d'autre choix que d'effectuer manuellement la requête ajax ailleurs.

Une autre chose qui me vient à l'esprit est le chaînage d'action asynchrone que j'ai vu dans certains documents. Nous n'avons pas eu besoin d'enchaîner les demandes de cette manière, donc je ne sais pas à quel point cet enchaînement est largement utilisé, mais j'ai l'impression que ce serait en dehors de la portée de ce que je propose ici (et peut-être ne relèvent pas du cas d'utilisation à 90 % mentionné dans cette discussion).

En conclusion, il semble tout à fait possible qu'une abstraction comme celle-ci aide à faciliter la courbe d'apprentissage et la quantité de code nécessaire pour écrire des applications Redux courantes. Quelqu'un a-t-il une idée de cette approche - des briseurs d'accord auxquels vous pouvez penser ? @markerikson @gaearon

Art antérieur : redux-axios-middleware

Beaucoup de choses se passent dans ce fil.

Concernant la discussion sur la complexité Redux. Personnellement, je ne suis pas d'accord avec les gens qui se plaignent que Redux soit compliqué et verbeux. C'est un compromis que vous faites lorsque vous optez pour une bibliothèque de bas niveau basée sur les architectures Flux & Elm. Il est indiqué dans la page d'accueil Redux que vous n'en aurez peut-être pas besoin. Mais nous avons encore des gens qui se plaignent que c'est compliqué.

Redux est trouvé tel quel. Heureusement, l'équipe de base est consciente qu'elle est complète et ne souhaite pas la modifier. Les abstractions construites dessus sont impressionnantes et chacune d'entre elles a son propre cas d'utilisation. C'est ce que vous attendez d'une bonne bibliothèque de bas niveau bien conçue.

Je vois le problème non pas sur Redux lui-même, mais sur l'absence d'un moyen progressif et prêt à l'emploi de l'apprendre. Comme certains l'ont mentionné, React lui-même avait le même problème et create-react-app était la solution.

Peut-être que ce n'est même pas le problème puisqu'il existe des ressources impressionnantes pour cela (c'est-à-dire la série Egghead de Dan). Peut-être que les personnes souhaitant utiliser une bibliothèque qui résout des problèmes complexes sans aucune courbe d'apprentissage sont le problème.

Quoi qu'il en soit, ce n'est pas le sujet de ce fil.

@markerikson Je suis personnellement prêt à aider au développement de ce redux-starter .

_J'aimerais bien un nom plus cool_ :stuck_out_tongue:

Le passe-partout requis pour produire de nombreuses actions est à peu près le seul inconvénient que je vois avec le redux.

C'est très bas niveau, mais je pense que c'est super. C'est l'une des raisons pour lesquelles je préfère le paradigme de style Redux à MobX par exemple, même si je comprends son utilité et utiliserais MobX. Mais je serais seulement heureux de le faire maintenant que je comprends Redux. Parce que Redux (ou le modèle Redux en général), les données ne vont pas particulièrement "dans les coulisses". Généralement, partout où le code est en cours de traitement, vous l'avez écrit, et sinon, vous pouvez le comprendre (si vous avez pris le temps d'apprendre, nous en parlerons plus tard).

Le fait est que lorsque j'ai découvert Redux pour la première fois, c'était beaucoup à comprendre, mais c'était aussi simple. Quelque chose peut être à la fois difficile et simple. Cependant, à cause de cela, j'ai pensé : « Wow, ce concept est tellement logique ! Il est tellement logique que je parie que je pourrais le faire moi-même ! » Donc, pour mon premier projet, au lieu d'utiliser le package Redux, j'ai créé mon propre petit magasin Redux.

Faire cela m'a non seulement aidé à comprendre le concept de Redux, mais a beaucoup augmenté ma compréhension de Javascript lui-même ! (C'est du point de vue de quelqu'un qui ne savait presque rien des concepts de programmation fonctionnelle avant cela, donc votre kilométrage peut varier.) Le concept de Redux est vraiment très brillant dans sa simplicité, mais aussi incroyablement puissant.

Je pense que le fait est que depuis Redux est si populaire, c'est, euhh, "buzzwordy-ness" peut distraire les nouveaux arrivants à quel point cela fonctionne bien en Javascript. Donc, leur mentalité peut être "ok, j'ai React, Redux, etc etc, maintenant je vais être un programmeur incroyable et faire une excellente application!" Non pas qu'il y ait quelque chose de mal à cela. Mais ils peuvent se concentrer sur le simple fait de vouloir utiliser un nouvel outil brillant pour accélérer le processus de développement, sans comprendre ce qui fait fonctionner l'outil.

Une fois le concept compris, il devient très facile de faire en sorte que Redux (ou tout autre modèle de type Redux) fasse toutes sortes de choses. Je l'aime pour la même raison que j'aime React par rapport à d'autres outils (toujours géniaux) comme Angular. _C'est juste du Javascript._ C'est ainsi que fonctionne Javascript !
Si le passe-partout nécessaire peut être réduit grâce à un paradigme, ce serait formidable, mais je pense que c'est un petit prix à payer pour un powaaaaaa illimitédd.

OMI, tout cela « la verbosité est un compromis » n'est que du masochisme ; la verbosité est pas en service de quoi que ce soit, il est un sacrifice que vous faites à utiliser Redux du tout. Je ne blâme pas Redux ou javascript, je veux juste souligner que ce n'est pas une complexité essentielle. Elm gère tout ce que Redux réalise en moins de lignes et un code plus simple.

Nous écrivons donc mécaniquement le passe-partout. Jumpstate et similaires facilitent la vie, mais il y a des limites à ce que vous pouvez faire au moment de l'exécution, et avec le typescript/flow, jumpstate n'aide pas beaucoup. Mais le codegen est difficile, et personne ne veut ajouter une chose de plus à leur système de construction déjà surchargé.

Si je pouvais avoir quelque chose comme le code Elm qui a été traduit en Redux idiomatique... Soyez toujours mon cœur qui bat.

Voici quelques-unes de mes idées, j'espère ne pas répéter les commentaires précédents :

Les créateurs d'action peuvent être utilisés comme types d'action

actions.js

export function increase() {}

réducteur.js

import { increase } from './actions.js';
export default handleActions({
    [increase]: (state) => state + 1
}, 0);

Comme les fonctions ont des références uniques, nous pouvons les traiter comme des identifiants d'actions. Non compatible FSA mais économise beaucoup de code et évite les erreurs.

Les actions peuvent être envoyées de manière asynchrone

async function a() {

}
async function b() {
}
store.dispatch(a());
store.dispatch(b()); // b() will be dispatched after a() resolves

De cette façon, les créateurs d'actions peuvent être des fonctions asynchrones et pourtant les envoyer les unes après les autres. Comme je le vois dans de nombreuses situations, les gens n'auront pas besoin d'utiliser des solutions basées sur un middleware et cela économisera beaucoup de code passe-partout.
Ce concept est mis en œuvre par une usine de promesses à Delux

redux === passe-partout

https://github.com/Emilios1995/redux-create-module

mais je pense que cette fonction peut complètement vous sauver la vie.

Cela vaut la peine de faire la différence entre deux ensembles d'idées différents dans ce fil :

• un framework basé sur le redux « full service »
• fonctionnalités supplémentaires dans le noyau redux

Je suis d'accord avec @markerikson pour

Redux a une surface API assez petite : createStore , applyMiddleware , combineReducers , bindActionCreators , et compose . Mais la plupart d'entre elles sont des fonctions de commodité. Seuls createStore sont strictement nécessaires au fonctionnement de Redux. Pourquoi certains d'entre eux appartiennent-ils au noyau ?

• applyMiddleware crée une interface simplifiée pour stocker les amplificateurs. Mais plus important encore, applyMiddleware prend en charge l'_interface_ du middleware comme moyen standard d'ajouter des effets aux magasins de redux. L'écosystème middleware est possible car applyMiddleware a une interface relativement simple et permet aux utilisateurs d'exécuter plusieurs middleware à la fois.

• combineReducers fournit une forme pratique de composition de réducteur. C'est loin d'être la seule façon de composer des réducteurs, mais c'est certainement l'un des modèles les plus utiles. Mais sa présence dans le noyau redux signifie que ce n'est pas seulement commun mais _omniprésent_. Chaque application Redux non triviale que j'ai rencontrée utilise combineReducers pour créer le réducteur de racine. Le revers de la médaille est que, parce que combineReducers est la seule forme de composition de réducteur fournie avec Redux, de nombreux utilisateurs semblent croire que c'est la seule forme de composition de réducteur qui existe.

• bindActionCreators réduit une partie du passe-partout autour des actions de répartition. Mais perversement, bindActionCreators est aussi indirectement responsable d'une partie de la réputation de Redux pour le passe-partout. C'est parce que la simple existence de bindActionCreators encourage l'utilisation de créateurs d'action. Ceci est particulièrement visible lorsque l'on compare la prévalence des créateurs d'action (qui sont "approuvés" par bindActionCreators ) par rapport aux sélecteurs (qui sont documentés mais n'ont pas de fonction de base équivalente). J'ai vu de nombreuses bases de code utilisant react-redux où mapStateToProps sont toujours des sélecteurs "sur mesure", mais mapDispatchToProps est toujours une carte d'objets de créateurs d'action pré-écrits.

Aucun d'entre eux n'est essentiel à la fonctionnalité de Redux, mais tous sont essentiels à sa convivialité. Aucune de ces fonctions ne limite la flexibilité inhérente de Redux, mais en réifiant des modèles communs en fonctions appelables, elles rendent les choix moins intimidants. Et chacune de ces fonctions d'assistance soulève d'autres questions :

• Si le middleware est une simplification des amplificateurs de magasin, existe-t-il d'autres simplifications qui pourraient être largement utiles ?
• Quelles autres formes de composition de réducteur pourraient être mises en œuvre au lieu d'être simplement documentées ? Objets réducteurs ? Réducteurs dépendants ? Composition linéaire ?
• L'intégration de reselect conduirait-elle les gens à créer et composer des sélecteurs là où ils ne l'avaient pas fait auparavant ? Serait-ce un net positif?

Même si les réponses à toutes ces questions sont négatives, je pense que nous nous rendons un mauvais service à nous-mêmes et à la communauté en refusant même de considérer leurs locaux.

@modernserf : Tout d'abord, merci pour vos commentaires, ainsi que vos autres réflexions récentes sur Redux. Ils sont tous _extrêmement_ précieux et informatifs, et devraient probablement être une lecture obligatoire pour toute autre personne dans ce fil. Donc, je vais les lier ici:

• Le post principal : Qu'est-ce qui est si génial avec Redux ?
• Une version storifiée du fil Twitter qui a mené à la publication : https://storify.com/acemarke/redux-pros-cons-and-limitations
• Quelques réflexions supplémentaires par la suite : https://twitter.com/modernserf/status/886426115874717697

Il est très intéressant que vous les souleviez, en raison de l'histoire impliquée (que je viens de passer beaucoup de temps à rechercher pour mon article The Tao of Redux, Part 1 - Implementation and Intent . En particulier, redux-thunk était à l'origine intégré à Redux , et react-redux n'a été séparé que plus tard également .

Vous avez raison de dire que ces utilitaires codifient effectivement certains modèles d'utilisation. Cela dit, ces utilitaires sont inclus car ils codifient les modèles d'utilisation _intentionnés_ : composition de réducteurs de tranches, un pipeline d'intergiciels pour le comportement asynchrone et d'autres comportements centralisés, et les créateurs d'actions liés pour simplifier le processus de répartition des actions à partir des composants (en particulier en passant des fonctions autour aux composants enfants). Un peu de la même manière, alors que Reselect n'est pas dans le noyau, Dan a explicitement encouragé sa création .

Alors oui, n'importe qui « aurait pu » les écrire, mais en les intégrant, nous avons poussé les gens à utiliser ces outils spécifiques de manière spécifique. Tout à fait d'accord là-dessus.

Par vos trois dernières questions :

• Je suppose que vous pourriez dire que les middlewares sont "une simplification des amplificateurs de magasin", bien que je ne pense pas que cela leur rende justice. Il s'agit plutôt d'un amplificateur de magasin dans un but très spécialisé. En ce qui concerne les autres travaux liés aux amplificateurs de magasin : Dan a déclaré que la partie principale du noyau Redux qu'il aimerait encore modifier concerne la façon dont les amplificateurs sont initialisés. Il existe en fait deux PR "concurrents" pour modifier l'implémentation de l'amplificateur de magasin qui sont ouverts depuis très longtemps : la version de @acdlite en #1706 et la version de @jimbolla en #2214. Il est également intéressant de noter que Jim a dressé une liste de tous les amplificateurs de magasin connus pour aider à analyser comment la communauté les utilise réellement. Je sais que la proposition de Jim visait à aider les auteurs d'enrichisseurs à simplifier les comportements couramment observés. C'est donc une piste qui pourrait être explorée plus avant.
• Il existe certainement de nombreux autres modèles pour la composition et la structure des réducteurs. Je ne sais pas exactement ce que nous pourrions faire en ce qui concerne les réducteurs "dépendants", car il s'agit d'un cas d'utilisation beaucoup plus spécialisé et semblerait être assez spécifique à l'application. Sur une note connexe, pendant longtemps, Dan avait fermé tous les PR qui proposaient d'ajouter une sorte de troisième argument à combineReducers (et il y en a eu beaucoup_), mais a finalement autorisé #1768 à avancer pendant un tandis que. Ce PR a également calé.
• Le cas d'utilisation le plus courant des sélecteurs semble être l'extraction directe de bits d'état et leur transmission en tant qu'accessoires nommés. Nous avons également un PR ouvert à React-Redux pour l' ajout d'une syntaxe abrégée d'objet pour mapState , et nous avons eu de nombreuses demandes pour cela même si vous pouvez faire la même chose avec createStructuredSelector Reselect.

Comme je l'ai documenté dans ce post "Tao of Redux", les objectifs déclarés étaient de garder l'API de base de Redux aussi minimale que possible et d' encourager un écosystème au-dessus . De plus, au début du développement de Redux, Andrew a fait un commentaire sur l'intention de "bénir" certains plugins :

Comme Gaearon l'a dit une fois, (je ne me souviens plus où... probablement Slack) nous visons à être comme les bibliothèques Koa of Flux. Finalement, une fois que la communauté sera plus mature, le plan est de maintenir une collection de plugins et d'extensions "bénis", éventuellement sous une organisation GitHub reduxjs.

Auparavant, j'avais proposé une sorte de bibliothèque d'abstraction « d'installation Redux facile », ou quelque chose comme ça. Est-ce que quelque chose comme ça, ou au moins cette liste d'addons « bénis », serait suffisant dans le sens que vous pensez ? (Et, en fait, vous l'avez fait aussi dans le premier commentaire de ce fil.) Sinon, des propositions ou des idées supplémentaires ?

Finalement, une fois que la communauté sera plus mature, le plan est de maintenir une collection de plugins et d'extensions "bénis", éventuellement sous une organisation GitHub reduxjs.

C'est ce que je ferais aussi, même si j'irais probablement plus loin : je restructurerais le projet en un monorepo, où le package redux actuel deviendrait quelque chose comme @redux/core , béni les bibliothèques telles que reselect et redux-action sont importées dans le référentiel et l'espace de noms, et le package redux lui-même réexporte simplement tous ces packages dans un seul espace de noms.

Cette _sorte de_ satisfait la contrainte de ne pas modifier le noyau redux. De plus, la version étendue serait un sur-ensemble strict de - et donc rétrocompatible avec - le noyau. Les nouvelles fonctionnalités seraient purement facultatives et n'auraient pas d'accès spécial à l'État privé. En ce qui concerne le "ballonnement", chacune de ces bibliothèques est petite pour commencer, et elles sont écrites de telle manière qu'il serait trivial de les secouer.

Nous avons également un PR ouvert à React-Redux pour l'ajout d'une syntaxe abrégée d'objet pour mapState, et avons eu de nombreuses demandes pour cela même si vous pouvez faire la même chose avec createStructuredSelector Reselect.

Je pense que cela devrait vous dire quelque chose.

La structure monorepo que je suggère est essentiellement la structure utilisée par Lodash. Maintenant -- Lodash est une bibliothèque intéressante à modéliser : c'est une énorme collection de fonctions, dont beaucoup sont triviales à implémenter vous-même. Presque toutes les fonctions de lodash pourraient être plus flexibles en tant que "recette" -- groupBy est vraiment un _modèle_ après tout ; qui sommes-nous pour dire sur quelles structures de données vous l'utilisez ?

Et chaque fonction lodash est également disponible dans sa propre bibliothèque _à la carte_. Il n'y a aucun avantage _fonctionnel_ à import { groupBy } from "lodash" dessus de import groupBy from "group-by" . Pourquoi devrais-je faire face au tremblement des arbres alors que je peux simplement installer ce dont j'ai besoin ?

Mais l'expérience d'utilisation de Lodash est fondamentalement différente de l'utilisation de recettes ou de nanobibliothèques. Vous savez que si vous faites quelque chose avec un tableau et que vous avez l'impression de vous répéter, il existe probablement une fonction Lodash pour le faire. Vous n'avez pas besoin de rechercher une recette, vous n'avez pas besoin d'installer quoi que ce soit - il est probable que vous n'ayez même pas besoin d'ajouter une autre ligne d'importation au fichier. Cela n'élimine que la plus petite quantité de friction, mais nos journées sont remplies de moments comme celui-ci et cela s'additionne.

J'espère que cela ne vous dérange pas que j'ajoute mes propres 2 cents, d'un point de vue différent.

Les écoles de pensée CQRS , Event Sourcing et, finalement, Domain Driven Design sont les plus grands ancêtres qui nous ont ennuyés Flux et Redux . Bien que ces influences soient parfois citées , Redux et ses outils descendants ont tiré la plupart de leur terminologie API des implémentations Flux et Flux qui étaient populaires à l'époque. C'est bien, mais je pense que nous passons à côté d'une occasion de profiter de l'exposition existante que les développeurs ont pu avoir sur ces idées.

Pour donner deux exemples de la différence : dans la plupart des discussions sur l' approvisionnement d'événements que j'ai vues, les actions Redux seraient appelées événements . Redux ActionCreators serait appelé Commands . Je pense que cette terminologie apporte également une clarté et une sémantique supplémentaires. Les événements sont des données enregistrables et sérialisables. Les événements décrivent ce qui s'est passé au passé. Les événements peuvent être rejoués. Les événements ne peuvent pas être non enregistrés. Les commandes ont une humeur impérative. Les commandes déclenchent des événements .

Je soupçonne que Event Sourcing en tant que modèle architectural gagnera en popularité au cours de la prochaine décennie, et je pense que Redux pourrait gagner en convivialité, en clarté et en facilité d'utilisation en alignant l'API et la discussion plus étroitement avec la communauté au sens large.

Je pense que cette discussion était déjà battue à mort : https://github.com/reactjs/redux/issues/351

Oh, je n'étais pas au courant, merci ! :+1:

Il semble que le #351 ait été fermé car à l'époque, aucune mesure ne pouvait être prise. Si nous sommes à un moment où nous reconsidérons les décisions de l'API et le langage que nous utilisons, cela me semble être le moment approprié pour refaire surface l'idée, pour moi.

Je peux être plus concret.

Voici mon idée de ce à quoi pourrait ressembler une API inspirée des idiomes Event Sourcing :

notions

• Flux d'événements observables
• Event Stream a un ensemble bien typé d'événements pris en charge
• Envoi de commandes au flux d'événements
• Un ou plusieurs clients consomment le flux d'événements

API

import { createEventStream, createProjection } from 'redux';

// Initialize the event stream separately from the store.  This becomes the one
// true source of truth for your application.
const eventStream = createEventStream({
  // Commands are the only thing that we want to couple to the eventStream.  The 
  // set of events which may end up in an eventStream should be easy to predict.
  //
  // A definition like this supports static analysis inference well for 
  // consumers that can leverage it.
  increment: () => ({ type: 'INCREMENT' }),
  decrement: () => ({ type: 'DECREMENT' }),
});

// Multiple stores with disjoint or overlapping data can be used to consume the 
// same event stream.
const store = createProjection(eventStream, reducer, init);
const adminStore = createProjection(eventStream, adminReducer, init);

// We don't need a jargon term ("Middleware"), or a dedicated hook to handle 
// async anymore.  We just register more subscribers to the eventStream.
eventStream.subscribe(myCustomMiddleWare);
eventStream.subscribe(sendEventsToAnalytics);
eventStream.subscribe(logEventsForPlayback);

// Calls to commands can be wrapped with React Providers or container components 
// in the same way that Redux currently does.  They can also be called directly.
eventStream.increment();

@ajhyndman : bien que j'apprécie la suggestion et la discussion, ce hangar à vélos a totalement été peint et le cheval a fui la grange (pour mélanger complètement les métaphores). Dan a choisi d'utiliser la terminologie Flux plutôt que les termes CQRS/ES, et il n'est pas prévu de modifier les API de base ou les termes utilisés pour les concepts Redux.

(De plus, bien que je n'aie aucune statistique pour étayer cela, je suppose qu'à ce stade, il y a plus de personnes familières avec l'utilisation par Redux des "actions" et des "créateurs d'action" qu'avec la terminologie CQRS/ES, du moins au sein de la communauté JS. )

J'ai définitivement l'impression que cette conversation a déjà eu lieu et qu'il y a une forte envie de ne pas la rouvrir. Je n'appuierai pas trop fort ici. (Je serais intéressé à lire ou à poursuivre cette conversation ailleurs, s'il y a un meilleur point de contact.)

Bien sûr, vous avez également raison de dire qu'il y a un facteur d'enracinement, et changer toute la surface et la terminologie de l'API serait coûteux à ce stade.

Je dirais toujours qu'il y a une opportunité pour les communautés Event Sourcing et Redux d'apprendre les unes des autres.

• Quelles abstractions possibles pourraient être créées pour simplifier le processus d'apprentissage et d'utilisation, mais sans masquer réellement Redux (et fourniraient, espérons-le, un chemin de migration/d'apprentissage pour « base » Redux) ?

Même sans emprunter la terminologie ou changer l'API, je pense qu'il y a des gains que nous pouvons trouver. Par exemple, j'ai réussi à présenter Redux aux gens en décrivant un magasin comme "un conteneur d'état dans lequel currentState est une" fonction pure de " (il est dérivé de, ou réduit de) une liste d'ajout uniquement (ou un flux) d'Actions".

En regardant plus loin dans le futur, je pense qu'il est tout à fait possible d'implémenter et d'abstraire une infrastructure de serveur de type redux (voir : Apache Samza , et certains des autres travaux de l'équipe d'ingénierie de LinkedIn). Si nous aspirons à cela, il devrait également être possible d'utiliser des abstractions similaires pour la gestion de l'état des clients et des serveurs ! Si nous pouvons y parvenir, pourquoi pas un magasin Redux isomorphe et persistant ?

Tous les concepts sur lesquels les communautés JavaScript et Infrastructure sont capables de se réunir ou de se mapper facilement, plus je m'attends à ce que ces opportunités deviennent apparentes rapidement et plus les abstractions sont expressives.

Je suppose que je suis juste un peu enthousiasmé par certaines de ces idées ! J'espère que vous me pardonnerez le mot dépotoir.

Remarque : il semble possible de créer une API wrapper de type flux d'événements pour Redux qui implémente la surface que j'ai suggérée ci-dessus !

https://github.com/ajhyndman/redux-event-stream

@ajhyndman Je pense que l'emballage est la bonne façon d'aller avec votre idée là-bas 👍

En ce qui concerne le travail d'ingénierie de samza et de linkedin que vous avez mentionné, si d'autres n'ont pas lu/regardé le merveilleux discours Retourner la base de données à l'envers avec Apache Samza, veuillez trouver une heure pour le faire de temps en temps ! Je pense avoir vu Dan le mentionner dans un fichier readme ou un tweet à un moment donné.

Cette vidéo est géniale ! C'est aussi en fait le deuxième élément de la liste des remerciements sur le README du référentiel redux .

Salut tout le monde!

Sans être au courant de l'existence de ce fil, j'ai développé une bibliothèque qui est en quelque sorte une réponse directe à @markerikson « s questions originales et des coups hors de la plupart des choses @gaearon » s liste .

La bibliothèque s'appelle Kea :

C'est une abstraction sur redux, redux-saga et resélectionner. À l'exception de la colle qui les relie, Kea ne prétend pas créer quoi que ce soit de nouveau et expose les créateurs et les réducteurs d'action de redux bruts, les sagas de redux-saga bruts et les sélecteurs de resélection bruts selon les besoins. Il n'invente pas de nouveau concept.

Kea prend en charge de nombreux modes de fonctionnement différents : vous pouvez l'utiliser de manière autonome, connecté aux composants React, aligné au-dessus des composants React ou même connecté dynamiquement aux composants React où l'entrée des sélecteurs dépend des accessoires du composant React.

Personnellement, je l'utilise avec deux grandes applications : une place de marché pour les cours particuliers et un énorme logiciel de suivi de flotte. De plus, je connais des gens qui ont construit leurs propres applications avec. Parce qu'il nous était si utile, j'ai passé un temps considérable à le nettoyer et à rédiger la documentation .

Pour moi, cette bibliothèque a toujours considérablement réduit le passe-partout, tout en restant fidèle au cœur du redux lui-même.

Bref, assez parlé, voici du code. Ceci est un exemple de ce que j'appelle "inline kea" - où la logique est directement attachée à votre composant. Ce mode est idéal lorsque vous débutez ou comme alternative au setState de React.

import React, { Component } from 'react'
import PropTypes from 'prop-types'
import { kea } from 'kea'

@kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

Si votre application grandit et que davantage d'endroits ont besoin d'accéder aux actions increment et decrement ou à la prop counter , vous pouvez simplement diviser votre code comme suit :

// counter-logic.js
import PropTypes from 'prop-types'
import { kea } from 'kea'

export default kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})

// index.js
import React, { Component } from 'react'
import { connect } from 'kea'

import counterLogic from './counter-logic'

@connect({
  actions: [
    counterLogic, [
      'increment',
      'decrement'
    ]
  ],
  props: [
    counterLogic, [
      'counter',
      'doubleCounter'
    ]
  ]
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

Veuillez l'essayer et lire la documentation pour en savoir plus sur les effets secondaires de redux-saga et d'autres fonctionnalités que vous pouvez utiliser.

Les retours pour Kea ont été extrêmement positifs jusqu'à présent, citant un numéro : "Plus de gens devraient utiliser KeaJS pour faire du monde redux un endroit meilleur ! 👍" :)

Merci pour votre temps et d'avoir lu jusqu'ici ! :)

À l'air cool! n'aimant pas vraiment les chaînes magiques bien que 'increment'

Cette discussion a-t-elle avancé ailleurs ? De Kea est-il le résultat le plus correct qui est généralement accepté ?

@lucfranken : non, la discussion a tourné court.

Si vous recherchez une abstraction de niveau supérieur sur Redux, alors Kea est probablement une bonne option. Si vous recherchez un "pack de démarrage Redux" qui simplifie le processus de configuration du magasin, vous devrez peut-être en chercher. Je sais que j'ai vu des choses comme ça dans la nature, mais nous n'avons pas de lib officielle comme ça pour le moment.

Je jette mon chapeau dans le ring ici. Voici comment j'aborde ce problème : https://github.com/HenrikJoreteg/redux-bundler

Personnellement, je pense que c'est une grande simplification et une réduction du passe-partout.

C'est comme ça que j'ai construit tout ce que j'ai construit récemment.

Je suppose que ça aiderait :
https://github.com/anish000kumar/redux-box

Hé, dans mon entreprise, nous venons d'ouvrir une bibliothèque qui gère la couche réseau et supprime beaucoup de passe-partout de Redux. Cela a fait ses preuves pour nous, mais essayez-le vous-même : https://github.com/Brigad/redux-rest-easy/ (article moyen : https://engineering.brigad.co/introducing-redux-rest-easy -6e9a91af4f59)

voici mon approche pour réduire le passe-partout redux

https://github.com/zhDmitry/restate

En tant que nécrosage très tardif du fil, il y a quelque temps, j'ai demandé des commentaires sur Twitter sur ce que "passe-partout" signifie pour les gens :

https://twitter.com/acemarke/status/969040835508604929

Le retour du Necro-Thread !

Selon mon édition du premier commentaire de ce fil, les idées discutées ici ont été transformées en notre package Redux-Starter-Kit . Veuillez l'essayer et voir à quel point cela peut vous aider à simplifier votre utilisation de Redux !