React Context vs React Redux, quand dois-je utiliser chacun d'eux? [fermé]


187

React 16.3.0 est sorti et l' API de contexte n'est plus une fonctionnalité expérimentale. Dan Abramov (le créateur de Redux) a écrit un bon commentaire ici à ce sujet, mais cela faisait 2 ans que le contexte était encore une fonctionnalité expérimentale.

Ma question est, à votre avis / expérience, quand dois-je utiliser React Context sur React Redux et vice versa?


Si vous comparez l'API de contexte Redux et React, c'est parce que vous souhaitez uniquement garder les variables synchronisées entre les composants. Vérifiez le duixpackage npm. Ce n'est qu'un simple gestionnaire d'état avec des rappels, vraiment facile à implémenter. Juste pour être clair: je suis le créateur.
Broda Noel

Réponses:


208

Car Context n'est plus une fonctionnalité expérimentale et vous pouvez utiliser Context directement dans votre application et sera idéal pour transmettre des données à des composants profondément imbriqués pour lesquels il a été conçu.

Comme Mark Erikson l'a écrit dans son blog :

Si vous n'utilisez Redux que pour éviter de transmettre des accessoires, le contexte pourrait remplacer Redux - mais vous n'avez probablement pas besoin de Redux en premier lieu.

Le contexte ne vous donne pas non plus Redux DevToolsla possibilité de suivre vos mises middlewareà jour d'état, d'ajouter une logique d'application centralisée et d'autres fonctionnalités puissantes qui Redux permettent.

Reduxest beaucoup plus puissant et fournit un grand nombre de fonctionnalités que le Context Apine fournit pas, également comme l'a mentionné @danAbramov

React Redux utilise le contexte en interne, mais il n'expose pas ce fait dans l'API publique. Vous devriez donc vous sentir beaucoup plus en sécurité en utilisant le contexte via React Redux que directement car si cela change, le fardeau de la mise à jour du code sera sur React Redux et non sur vous.

Il est jusqu'à Redux pour mettre à jour son implémentation pour adhérer à la dernière API contextuelle

La dernière API de contexte peut être utilisée pour les applications où vous utiliseriez simplement Redux pour transmettre des données entre les composants, mais les applications qui utilisent des données centralisées et gèrent la demande d'API dans les créateurs d'action utilisant redux-thunkou redux-sagaauraient encore besoin de redux. En dehors de ce redux, d'autres bibliothèques sont associées, telles redux-persistque celles qui vous permettent de sauvegarder les données de stockage dans localStorage et de les réhydrater lors de l'actualisation, ce que l'API de contexte ne prend toujours pas en charge.

Comme @dan_abramov l'a mentionné dans son blog, vous n'avez peut-être pas besoin de Redux , ce redux a une application utile comme

  • Conserver l'état sur un stockage local, puis démarrer à partir de celui-ci, hors de la boîte.
  • Pré-remplissez l'état sur le serveur, envoyez-le au client en HTML et démarrez à partir de celui-ci, prêt à l'emploi.
  • Sérialisez les actions des utilisateurs et associez-les, avec un instantané de l'état, à des rapports de bogues automatisés, afin que les développeurs de produits
    puissent les rejouer pour reproduire les erreurs.
  • Passez des objets d'action sur le réseau pour implémenter des environnements collaboratifs sans changer radicalement la façon dont le code est écrit.
  • Maintenez un historique des annulations ou implémentez des mutations optimistes sans changer radicalement la façon dont le code est écrit.
  • Voyagez entre l'historique des états en cours de développement et réévaluez l'état actuel à partir de l'historique des actions lorsque le code change, à la TDD.
  • Fournissez des capacités d'inspection et de contrôle complètes aux outils de développement afin que les développeurs de produits puissent créer des outils personnalisés pour leurs
    applications.
  • Fournissez des interfaces utilisateur alternatives tout en réutilisant la plupart de la logique métier.

Avec ces nombreuses applications, il est bien trop tôt pour dire que Redux sera remplacé par la nouvelle API de contexte


Ok, mais qu'en est-il de la réutilisabilité? Les contextes sont totalement réutilisables, une fois redux + thunk, et surtout redux + saga le sont à peine.
Yurii Haiovyi

4
@Daggett Une chose que nous devons comprendre est que redux n'est pas un contexte, il est construit au-dessus du contexte, le magasin que vous avez est transmis par contexte, pouvez-vous également élaborer ce que vous entendez par réutilisabilité
Shubham Khatri

Même le développement d'une chose aussi basique comme un conteneur réutilisable avec des effets secondaires devient un cauchemar avec redux. Redux est serré au niveau de l'application, et vous pouvez dire qu'il est toujours réutilisable, etc. etc., mais en disant réutilisable, je veux dire totalement réutilisable ... Sans spaghetti de pointes, construit comme un package séparé, et pourrait être réutilisé indépendamment pour la configuration de l'application .
Yurii Haiovyi

@YuriiHaiovyi Je suis d'accord avec vos questions. Cette réponse est essentiellement une version compilée de ce que disent les articles de blog liés. Rien sur le partage de ma propre perspective, comme je n'utilisais que le contexte, puis je suis resté coincé, et j'ai pensé que c'était un mauvais choix pour certaines raisons x, y, z, puis je suis passé à Redux, Mobx qui l'a résolu ... ou l'inverse histoire par exemple. Principalement les gens demandent ou recherchent ceci pour voir s'il y a des histoires mauvaises ou bonnes qui peuvent alors aider les lecteurs à réfléchir et à prendre des décisions calculées ... Alors ma question quel chemin vous choisissez?
Arup Rakshit

4
Quelle partie de redux n'est pas réutilisable? Vous pouvez facilement réutiliser des réducteurs, des sélecteurs, des actions et des créateurs d'actions dans une autre application avec redux (réaction, même angulaire).
Dávid Molnár

85

Si vous utilisez Redux uniquement pour éviter de transmettre des accessoires à des composants profondément imbriqués , vous pouvez remplacer Redux par l' ContextAPI. Il est exactement destiné à ce cas d'utilisation.

D'autre part, si vous utilisez Redux pour tout le reste (avoir un conteneur d'état prévisible, gérer la logique de votre application en dehors de vos composants, centraliser l'état de votre application, utiliser Redux DevTools pour suivre quand, où, pourquoi et comment l'état de votre application changé, ou en utilisant des plugins tels que Redux Form , Redux Saga , Redux Undo , Redux Persist , Redux Logger , etc…), alors il n'y a absolument aucune raison pour vous d'abandonner Redux. L' ContextAPI ne fournit rien de tout cela.

Et je pense personnellement que l'extension Redux DevTools est un outil de débogage étonnant et sous-estimé, qui justifie à lui seul de continuer à utiliser Redux.

Quelques références:


12

Je préfère utiliser redux avec redux-thunk pour passer des appels API (également en utilisant Axios) et envoyer la réponse aux réducteurs. C'est clair et facile à comprendre.

L'API de contexte est très spécifique à la partie react-redux sur la façon dont les composants React sont connectés au magasin. Pour cela, react-redux est bon. Mais si vous le souhaitez, puisque le contexte est officiellement pris en charge, vous pouvez utiliser l'API de contexte au lieu de react-redux.

Ainsi, la question devrait être API de contexte vs react-redux, et non API de contexte vs redux. En outre, la question est légèrement opiniâtre. Depuis, je suis familier avec react-redux et je l'utilise dans tous les projets, je continuerai à l'utiliser. (Il n'y a aucune incitation pour moi à changer).

Mais si vous apprenez le redux juste aujourd'hui et que vous ne l'avez utilisé nulle part, il vaut la peine d'essayer l'API de contexte et de remplacer react-redux par votre code d'API de contexte personnalisé. Peut-être que c'est beaucoup plus propre comme ça.

Personnellement, c'est une question de familiarité. Il n'y a pas de raison claire de choisir l'un plutôt que l'autre car ils sont équivalents. Et en interne, react-redux utilise quand même Context.


10

Les seules raisons d'utiliser Redux pour moi sont:

  • Vous voulez un objet d'état global (pour diverses raisons, comme la débuggabilité, la persistance ...)
  • Votre application est ou sera grande, et devrait s'adapter à de nombreux développeurs: dans ce cas, vous avez probablement besoin d'un niveau d'indirection (c'est-à-dire un système d'événements): vous déclenchez des événements (dans le passé) et ensuite des personnes que vous ne connaissez pas dans votre l'organisation peut réellement les écouter

Vous n'avez probablement pas besoin du niveau d'indirection pour l'ensemble de votre application, c'est donc bien de mélanger les styles et d'utiliser l'état / contexte local et Redux en même temps.


1
  • Si vous devez utiliser un middleware à des fins diverses. Par exemple, les actions de journalisation, les rapports d'erreur, l'envoi d'autres demandes en fonction de la réponse du serveur, etc.
  • Lorsque les données provenant de plusieurs points de terminaison influencent un seul composant / vue.
  • Lorsque vous souhaitez avoir un meilleur contrôle sur les actions de vos applications. Redux permet le suivi des actions et des changements de données, il simplifie considérablement le débogage.
  • Si vous ne souhaitez pas que la réponse du serveur modifie directement l'état de votre application. Redux ajoute une couche dans laquelle vous pouvez décider comment, quand et si ces données doivent être appliquées. Le modèle d'observateur. Au lieu de créer plusieurs éditeurs et abonnés sur l'ensemble de l'application, vous connectez simplement des composants au magasin Redux.

De: Quand utiliser Redux?

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.