web-dev-qa-db-fra.com

React hooks: sont-ils utiles pour la gestion d'état partagée, comme par exemple Redux?

Il y a un battage médiatique à propos de React hooks. Trop d'informations et je ne sais toujours pas: l'arrivée des hooks signifie-t-elle que des bibliothèques comme Redux peuvent être jetées à la poubelle?

Jusqu'à présent, ce que j'ai compris, c'est que les crochets sont bons pour les composants fonctionnels avec état, qu'en est-il de l'état partagé?

reactjsreduxstate-managementreact-hooks
6
Nurbol Alpysbayev

Non, les hooks n'éliminent pas totalement le besoin de Redux. Les crochets sont principalement une alternative pour implémenter des fonctionnalités que nous devons utiliser pour les classes d'aujourd'hui:

  1. État du composant local
  2. Le contexte
  3. Méthodes de cycle de vie et effets secondaires

Hormis ce qui précède, les crochets offrent également un moyen plus simple de partager une logique avec état entre les composants.

Ce qui est plus susceptible de tuer/remplacer Redux est context au lieu des hooks, ce qui est un moyen de partager l'état entre les composants. Mais le contexte IMO n'est pas aussi puissant que les magasins Redux car il existe d'autres fonctionnalités que Redux offre en plus d'un magasin d'état partagé comme les middlewares et un outil de développement spécialisé avec des capacités de voyage dans le temps. Il y a aussi tout un écosystème d'apprentissage et d'outils construit autour de Redux que le contexte n'a pas pour le moment pour autant que je sache.

Si vous utilisez le crochet useReducer en conjonction avec un contexte comme dans cet exemple , ce serait très similaire à l'utilisation de Redux et pour les petites applications (comme un TodoMVC), cela pourrait être suffisant . Pour les grandes applications, je ne pense pas qu'un seul contexte et useReducer seront suffisants. Vous pourriez avoir besoin de plusieurs d'entre eux, et c'est là que l'utilisation de Redux et la composition de magasins auraient du sens. Vous pouvez également combiner plusieurs contextes et des crochets useReducer mais il peut être plus propre d'utiliser simplement Redux.

12
Yangshun Tay

Non, les hooks ne remplaceront pas Redux, mais ils peuvent vous aider à écrire du code plus propre, et vous n'aurez pas besoin d'écrire des composants de classe uniquement pour utiliser l'état local ou des méthodes de cycle de vie. C'est un excellent cas d'utilisation ici.

Dans le passé, vous deviez utiliser Redux pour vous assurer qu'un état est persistant entre chaque re-rendu du composant. Mais maintenant, vous pouvez simplement utiliser la méthode useState () pour implémenter un état local persistant! Vous pouvez utiliser useEffect () au lieu des méthodes React cycle de vie), et vous pouvez utiliser useReducer pour écrire des méthodes de création d'actions rapides et accéder à un état global !!

Voici un bon article sur la façon d'utiliser la méthode useReducer ().

2
xeiton

Oui mais il semble que ce ne soit toujours pas une fonctionnalité officielle. C'est toujours dans la proposition de fonctionnalité. étape. Beaucoup de gens pensaient que le contexte de réaction déverserait le redux dans la poubelle, mais il s'est avéré que non.

1
Auriga

Les crochets et le contexte ne sont pas destinés à gérer l'état de l'application au lieu de Redux.

Le contexte s'apparente davantage à des accessoires en ce qu'il résout le cauchemar que peut devenir la communication d'informations d'un parent à un enfant dans de grandes applications d'entreprise fortement imbriquées. L'inconvénient est que le contexte est un peu plus complexe et sa configuration peut être douloureuse.

Les crochets nous permettent simplement d'utiliser des composants fonctionnels qui peuvent désormais se connecter à l'état d'application sans avoir à les transformer en composants basés sur les classes.

La confusion réside dans le fait que vous pouvez récupérer des fonctionnalités de Redux avec un crochet comme useReducer sans la configuration Redux traditionnelle.

Donc, comme si vous travailliez sur une application de blog et que vous vouliez ajouter des fonctionnalités pour mettre à jour vos articles de blog, vous pouvez appliquer useReducer comme ceci:

const blogReducer = (state, action) => {
  switch (action.type) {
    case 'add_blogpost':
      return [...state, { title: `Blog Post #${state.length + 1}` }];
    default:
      return state;
  }
};

Ce serait donc votre réducteur que vous appliqueriez alors comme suit:

export const BlogProvider = ({ children }) => {
  const [blogPosts, dispatch] = useReducer(blogReducer, []);

Vous pouvez créer temporairement une fonction d'assistance pour distribuer un objet d'action:

const addBlogPost = () => {
    dispatch({ type: 'add_blogpost' });
  };

Vous devez l'ajouter à votre accessoire de valeur, le 'add_blogpost'. Quoi qu'il en soit, c'est juste une façon déroutante d'utiliser des aspects de Redux sur un composant fonctionnel sans utiliser tout le système Redux lui-même, mais encore une fois, pas un remplacement.

0
Daniel

Attention s'il vous plaît, Redux est juste une gestion d'état. Pas une bibliothèque React. Vous pouvez utiliser Redux dans n'importe quel projet que vous souhaitez.

À l'avenir, peut-être que le connecteur redux (react-redux) sera tué ou inutilisé par les hooks, mais le Redux lui-même est une bibliothèque impressionnante car il apporte l'ordre dans une application qui doit gérer beaucoup de données et se développer par des tonnes de développeurs .

Il peut y avoir plus de cas d'utilisation où Redux n'est pas nécessaire, mais non, ni les hooks ni le contexte ne "tueront" Redux.

J'utilise Redux dans une application d'entreprise qui, auparavant, était un gâchis, il n'y avait aucune source de vérité. Redux a mis de l'ordre dans la base de code et la logique.

0
Pooya Sabramooz