Redux: Le temps de Redux est-il passé?

https://github.com/rackt/redux/issues/464

Beaucoup de gens sont plutôt satisfaits de Redux. Vous devriez demander autour de vous - je ne suis pas vraiment qualifié pour répondre à cette question. Je dirais que si votre application est très riche en données à la Facebook (de nombreuses entités imbriquées avec des relations complexes), c'est une bonne idée d'investir dans un backend GraphQL et d'apprendre Relay. Je n'en ai entendu que du bien.

Redux est bien sûr plus explicite et ne résout pas la récupération de données déclarative pour vous. Il y a des tentatives pour intégrer Redux et GraphQL mais je ne peux pas les évaluer par rapport à Relay - j'en sais trop peu à ce sujet.

Redux est un niveau beaucoup plus bas que Relay, et n'est pas plus «passé» que les objets et fonctions JS simples sont «passés». Relay est un framework, et Redux, sans les contrôles de cohérence, est composé de dix fonctions de 10 lignes, il ne devrait donc pas être surprenant qu'elles aient des portées différentes. Choisissez ce qui vous convient le mieux et faites-le nous savoir.

La récupération déclarative de GraphQL est incroyable, de premier ordre. Cependant, Relay a toujours une API HoC principalement, qui n'est pas déclarative en soi. Si Relay offrait une API plus flexible, découplée de l'arborescence des composants, alors une liaison Redux appropriée pourrait-elle être écrite?

Je pense que ce sont 2 types de systèmes qui résolvent 2 problèmes distincts.
Ce ticket est comme des charpentiers qui demandent si l'heure du marteau est passée.
Je dirais que les systèmes basés sur graphql sont une solution sur-conçue pour de nombreuses applications, à l'inverse, les applications avec des structures de données complexes sont très probablement sous-conçues si elles sont construites avec redux.

Je dirais que les systèmes basés sur graphql sont une solution sur-conçue pour de nombreuses applications, à l'inverse, les applications avec des structures de données complexes sont très probablement sous-conçues si elles sont construites avec redux.

Bonne façon de le mettre; c'est aussi ce que je ressens.

@gaearon continuez votre bon travail avec redux! L'un des meilleurs outils en cours! Je l'utilise dans 5 grandes applications et 2 petites dans mon entreprise et j'adore ça!

@gaearon continuez votre bon travail avec redux! L'un des meilleurs outils en cours! Je l'utilise dans 5 grandes applications et 2 petites dans mon entreprise et j'adore ça!

: 100:

je pense que ce n'est pas la même chose:

• relais - pour résoudre la gestion de la récupération des données depuis le serveur
• redux - pour résoudre la gestion de l'état de l'application

de nombreuses applications complexes contiennent un état qui n'est pas lié au serveur que vous devrez gérer. Je dirai que si vous utilisez le relais, vous verrez que vous aurez également besoin d'un redux. selon le contraire, le relais semble être un très bon coup de pouce mais uniquement pour les choses liées au serveur

La question est de savoir comment Relay se rapporte aux modèles de conception inspirés des flux? Où se termine Relay, quand avons-nous besoin de Redux? Est-ce que Relay Flux 2.0?

L'exemple de Todo Relay: rend-il redux obsolète?

Peut-être existe-t-il un moyen de dire à votre réducteur comment se mapper vers et depuis GraphQL et quand? Ne pas dire quelque chose qui ne soit pas complexe, mais quelle est la façon la plus simple de donner du sens.

Besoin d'en savoir plus sur ce qu'est Relay. Ce ne sont pas quelques centaines de lignes de code, c'est sûr!

@oriSomething Vous n'avez pas tout à fait raison. Relay résout également beaucoup de gestion d'état.

@gyzerok j'ai voulu dire l'état de l'application côté client

@oriSomething Oui, je parle de l'état de l'application côté client

@gyzerok je l'ai manqué. pouvez-vous me donner un lien à ce sujet?

@oriSomething il n'y a pas de lien spécial car Relay le gère implicitement. Peut-être que vous pouvez essayer de regarder les discussions de FB sur Relay. Ils parlent de la façon dont Relay résout le problème de cache. Cache d'application côté client = état. Je ne me souviens pas de propos définitifs, désolé.

@oriSomething le seul endroit où le développeur devrait faire une gestion d'état explicite est ici .

@gyzerok ok, alors dans ce cas, y a-t-il une gestion d'état qui n'est pas liée au serveur que fait le relais? pour autant que je sache, ce n'est pas le cas, ou est-ce?

@oriSomething Si je vous ai bien compris, Relay fait tout ce qui concerne la normalisation des données sur le client et la fusion des données des requêtes en un seul magasin.

@oriSomething oui, c'est le cas => https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
Vérifiez: https://facebook.github.io/relay/docs/guides-ready-state.html#content

Uniquement s'il n'y a pas suffisamment de données sur le client, Relay envoie une demande au serveur pour plus de données.

Redux est un niveau beaucoup plus bas que Relay, et n'est pas plus «passé» que les objets et fonctions JS simples sont «passés». Relay est un framework, et Redux, sans les contrôles de cohérence, est composé de dix fonctions de 10 lignes, il ne devrait donc pas être surprenant qu'elles aient des portées différentes.

J'ai donc créé slim-redux.js juste pour le plaisir - une version de Redux sans commentaires, avertissements du développeur et vérifications de cohérence. Il passe tous les tests essentiels de Redux (à l'exception des tests de vérification de cohérence), et c'est 99 lignes: wink:. Cela devrait sceller mon point de vue selon lequel Relay et Redux sont des outils avec des portées extrêmement différentes.

@IwanKaramazow je pense que je n'ai pas été assez clair, ce que j'essaie de dire, ce ne sont pas toutes les données qui concernent le serveur, il y a des données qui ne sont pas liées au serveur à gérer, et je ne pense vraiment pas que le relais est "l'outil" de référence même s'il peut gérer ces données

@oriSomething pouvez-vous donner un exemple?

Tout à fait d'accord @mattapperson . Tout se résume à la définition de complexe, ou mieux, à l'endroit où chaque individu reconnaît une «chose complexe»

@IwanKaramazow Je pense que @oriSomething parle de l'état du formulaire côté client par exemple

J'ai déménagé de Redux => Relay à cause de GraphQL. La plupart des ressources de mon application étaient hiérarchiques. Ils avaient naturellement du sens pour être des entités imbriquées. Garder un cache de ces modèles dans Redux était incroyable. J'avais une vision saine de mes données et je pouvais rapidement itérer avec l'impressionnant redux-devtools.

Mais sans GraphQL, j'ai dû faire plusieurs allers-retours pour mapper des ressources distantes à l'arbre redux.

1. / resource1-list
2. / resource2-list? resource1 =
3. / resource3-list? resource2 =

C'est évidemment un problème avec REST, pas avec Redux. Si j'avais vu des liaisons Redux-GraphQL plus tôt, je les utiliserais peut-être. L'adoption de Relay a très peu changé dans mon application. Au lieu de @connect j'utilise Relay.createContainer . Les deux produits ont la même vision de l'architecture avec des API différentes. J'ai écrit un article rapide à ce sujet.

J'utilise actuellement à la fois redux et relay / graphql et bien que relay soit incroyable pour la récupération de données, je peux me voir toujours en utilisant redux. J'utilise actuellement redux pour 2 raisons et je peux me voir trouver plus de raisons à l'avenir

1) État divers qui doit être partagé entre les composants qui ne résident pas dans la base de données
2) Préparation du formulaire. J'ai en fait une partie de mon application dans laquelle j'ai un composant de barre d'outils qui a un bouton d'envoi et un composant de panneau qui contient tous mes champs de saisie. Lorsque je tape dans le formulaire, je débonce mon entrée dans un "réducteur de formulaire" stocké dans redux afin que ma barre d'outils puisse avoir accès aux données avant de soumettre.

De plus, redux devtools est génial.

Homme oh mec. J'ai lu sur Relay aujourd'hui, et je dois admettre que le code n'est pas facile à lire ni à comprendre. J'ai regardé quelques exemples de Redux et j'ai pu saisir les concepts de base en lisant simplement le code.

Le tutoriel ou l'exemple Todo semblent tout sauf élégants. Je pense que React et FLUX sont fiers d'être simples. Je ne ressens pas encore ce sentiment de Relay.

Étant donné les liens étroits de Relay avec React et la complexité relative de la plupart des applications, j'ai été plus intéressé par Falcor ces derniers temps. En fait, en raison de son interface basée sur la promesse, il s'intègre très bien avec la façon dont vous faites la plupart des comportements asynchrones dans Redux. Et comme il est découplé de React, je peux l'utiliser partout dans mon application plus facilement. De plus, le rendu côté serveur n'est pas encore complètement cuit , ce qui n'est pas une solution pour moi.

J'apprécie également le résolveur de réaction , qui s'apparente à un "Relay Lite". Celui-ci peut finir par être le meilleur pour des projets très simples ou ceux qui reposent sur des API REST tierces.

@timdorr Avez-vous essayé de stocker tout votre état dans Falcor? Faire en sorte que vos réducteurs utilisent un objet Falcor, par exemple.

Pas encore. Je suis toujours en mode expérimental avec lui et j'ai de plus gros poissons à faire frire sur mes projets, donc je ne lui ai pas encore accordé suffisamment d'attention.

J'ai joué avec Falcor et je le recommande vivement. En fait, je travaille actuellement sur l'intégration d'une application Redux avec un backend Falcor. Il ne vous donne pas l'agrégation de requêtes de Relay, mais il a une couche de cache très sophistiquée dans sa bibliothèque cliente qui empêche la surexploitation. Je pense que cela pourrait suffire, mais le temps nous le dira.

@gaearon Comment l'écriture d'une application Web React avec la récupération de données déclarative se compare-t-elle à l'écriture de la même application dans Elm?

Il me semble que la principale différence est que la récupération des données est plus déclarative avec Relay & GraphQL (Elm vous demande de spécifier une URL, et c'est à vous de trier les données qui reviennent), et tout le reste est plus déclaratif dans Elm .

En fait, il semble que l'écosystème Elm pourrait bénéficier d'un portage Relay / GraphQL.

En ce qui concerne l'agrégation de requêtes, il existe la méthode Model.batch . Cela prend soit un intervalle (en millisecondes), soit un planificateur, mais je ne trouve pas beaucoup de documentation sur les planificateurs.

Si cela ne vous dérange pas de me demander, comment intégrez-vous Redux et Falcor? Toutes mes tentatives m'ont frustré.

Je serais également intéressé de voir un exemple de redux Falcor. J'ai lu tous les documents Falor et je suis d'accord que c'est beaucoup plus simple que relay / graphql. Bien que moins puissant.

Pour quiconque se pose des questions sur la relation de Redux avec Relay et s'il est judicieux de les utiliser ensemble, voir: https://github.com/facebook/relay/issues/114

L'essentiel est que Relay gérera éventuellement les données de plusieurs sources (backend, données éphémères locales, etc.), donc il remplace d'autres implémentations de Flux que vous utilisez peut-être.

https://github.com/facebook/relay/issues/168#issuecomment -135169255:

Notez que Relay est une implémentation du pattern Flux (Flux peut-il se remplacer? ;-).

Nous utilisons fortement Redux et Relay chez OpenGov. Il est vrai que depuis le passage à Relay, notre dossier reducers/ est devenu beaucoup plus petit. Cependant, nous avons constaté que Redux est toujours très utile pour la gestion de l'état local au niveau de l'application. Peut-être qu'un jour, Relay le supplantera également dans ce domaine. Mais comme @josephsavona l'a dit une fois, «l'architecture Redux» est vraiment juste ... fonctionne :) Même si un jour vous quittez la bibliothèque Redux, vous continuerez probablement à utiliser des mises à jour d'état immuables, un flux de données réactif, un réducteur fonctions, etc. pour un avenir prévisible. C'est l'élément précieux de Redux IMO, pas nécessairement la bibliothèque <100 lignes qui existe dans ce dépôt. (Oh, et la communauté, bien sûr.)

Je dirais que si votre application est très riche en données à la Facebook (de nombreuses entités imbriquées avec des relations complexes), c'est une bonne idée d'investir dans un backend GraphQL et d'apprendre Relay.

D'accord, mais je dirais que GraphQL + Relay est un bon investissement, même pour les applications de taille modeste, en particulier pour les nouveaux projets qui partent de zéro.

Que pensez-vous de https://github.com/gyzerok/adrenaline?

Ce n'est pas tout à fait approprié, car il n'utilise pas Relay, mais que pensez-vous de cette approche pleine d'opinion de la communauté Meteor? https://github.com/mattkrick/meatier

Seule une architecture profonde comme GraphQL / Relay ou Datomic / Om.Next peut résoudre le problème d'objet / d'impédance relationnelle ... Voici mes réflexions - retour apprécié.

GraphQL / Relay: la fin de Redux?

Il semble que beaucoup de gens s'intéressent à ce sujet (Relay / Redux, GraphQL et réduction de la complexité) Je travaille sur la conception d'un client GraphQL simple mais fonctionnel qui jouera très bien avec l'approche Redux de l'état des applications.

Curieux de savoir ce que les gens pensent de cet ensemble de principes de conception: https://github.com/apollostack/apollo-client/pull/7/files?short_path=83772ba

Juste ajouter mes 2cents ici: je ne pense pas qu'il y ait une fin à Redux. C'est simple et beau, et suffisant dans de nombreux cas. L'écosystème JS est si rapide et difficile à suivre, et Redux, comme React d'une certaine manière, est un jalon sur lequel nous pouvons compter pendant un certain temps. Nous ne pouvons tout simplement pas faire évoluer notre flux de travail tous les mois (ou du moins, je ne peux pas), et je pense que Redux est une très bonne option pour le moment. Le relais (et la récupération de données en général) n'est tout simplement pas nécessaire sur de nombreux projets…

@gaearon cela fait quelques mois que vous avez

@likeabbas si vous recherchez une intégration GraphQL-Redux, essayez Apollo Client: http://docs.apollostack.com/apollo-client/index.html

Nous n'avons pas encore 100% de parité des fonctionnalités avec Relay, mais nous nous rapprochons.

@gaearon pour faire écho à la question de @likeabbas : "Où diriez-vous que nous en sommes maintenant en termes d'intégration GraphQL avec Redux par rapport à Relay /, ou peut-être une combinaison des trois?"

Quelques brèves réflexions. 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 pouvant réutiliser des éléments tels que le débogueur graphique ou le middleware. Ce cas d'utilisation ne semble pas susceptible de disparaître, donc plutôt que "le temps de Redux est-il venu et passé", une question peut-être plus intéressante serait: si vous construisez un client GraphQL, est-il logique de construire sur Redux?

Ce à quoi je répondrais qu'il n'est pas certain qu'il y ait une seule bonne réponse. Construire sur Redux peut bénéficier de l'intégration (outils partagés, données partagées), tandis que la construction d'une approche personnalisée est plus de travail mais permet un outillage plus spécifique au domaine et peut permettre de meilleures performances. Comme pour beaucoup de choses dans le développement logiciel, cela dépend du cas d'utilisation!

@josephsavona : c'est un _great_ résumé de Redux! Nous devrons peut-être voler ça pour les documents quelque part :)

Oui, le titre de ce fil n'est pas optimal, et il semble que la question ait été un peu épuisée. Il est peut-être temps de déplacer la discussion ailleurs.

>.> lock the issue

Je vais juste clore ça. Je ne sais pas si une résolution doit être trouvée de toute façon. Redux fonctionne pour certaines personnes et c'est assez bien pour moi.

Oups, mauvais bouton. Désolé pour ça 😄