Réagissez à useContext avec "setState"

Question

J'ai récemment commencé à utiliser l'API Context React avec useContext Hook. J'ai observé que lorsque nous avons une variable d'état, c'est-à-dire const someState = useState(state, setState), certains développeurs passent setSate directement dans les valeurs du fournisseur, puis l'appellent dans les composants enfants. Est-ce une bonne pratique ?

Lorsque vous n'utilisez pas de contexte, vous devez créer un gestionnaire pour "accéder" à setState dans un composant enfant. J'utilise toujours des fonctions de gestionnaire et je les transmets aux valeurs du fournisseur pour les importer du contexte chez les enfants.

Est-ce que passer setState en contexte est une bonne pratique ? J'ai encore des doutes car normalement vous ne pouvez pas passer setState directement dans un composant. Y a-t-il une différence de performances ou d'autres inconvénients que je devrais prendre en compte ?

Merci.

Answer 1

Si j'ai bien compris, la différence est que d'une manière, l'état est défini à partir du composant parent et dans l'autre, l'état est défini à partir du composant enfant. Parfois, les gens le font de cette façon pour éviter le rendu en boucle avec changement d'état. Il ne devrait y avoir aucun inconvénient, mais l'utilisation des fonctions de gestionnaire est la méthode habituelle.

Answer 2

Edit : Je pense en fait que je me suis trompé, mais je ne suis pas sûr. Ma réponse est valable pour le cas si vous écrivez votre propre fournisseur qui a un état. Si vous utilisez simplement un fournisseur par défaut qui fournit un setter, je serais d'accord avec la réponse d'Amel.

---

Personnellement, je ne le ferais pas, mais c'est plus une opionion. Cependant, comme toujours, cela dépend en grande partie de l'objectif que vous souhaitez atteindre.

Un aspect positif de le faire est que les setters d'état donnés par useState restent toujours les mêmes pour chaque rendu. Si vous transmettez une valeur personnalisée, vous devez éviter qu'elle ne change trop souvent car chaque composant écoutant la modification à l'aide de useContext restituerait.

Je préférerais toujours passer un objet personnalisé (par exemple provenant d'un useMemo pour éviter les rendus inutiles) avec un rappel pour définir l'état. Il est plus facile de prolonger si vous souhaitez fournir plus de choses à l'avenir.

Quelque chose comme ça (exemple très simpliste, qui bien sûr n'a pas de sens comme ça, c'est juste pour la compréhension):

function MyProvider({children}) {
   const [state, setState] = useState(0);
   const provided = useMemo(() => ({
       value: state,
       setValue: (value) => setState(value)
   }, [value]);
   return <MyContext.Provider value={provided}>{children}</MyContext.Provider>;
}

Il serait plus facile d'étendre sans changer le code partout où le contexte est utilisé. Cependant, je pense toujours qu'il n'y a rien de particulièrement mauvais à ne passer que le passeur, si c'est ce que vous voulez atteindre.