Comment choisissez-vous entre l'état local, le Context et une bibliothèque d'état comme Redux ou Zustand ?

Faites correspondre l'outil à la nature de l'état. useState local pour tout ce qu'un seul composant possède, l'URL pour tout ce qui est partageable ou marquable, un cache de requêtes pour les données serveur, et le Context pour les valeurs stables comme le thème ou l'utilisateur courant. Ne sortez un store que quand vous avez un état client réellement global que beaucoup de composants sans lien lisent et écrivent, et où il vous faut des sélecteurs pour éviter de tout re-rendre.

J'essaie de déterminer de quelle sorte d'état il s'agit avant de choisir quoi que ce soit, parce que les plus gros gains viennent du fait de ne pas le mettre dans un store du tout. Les données serveur vont dans un cache de requêtes, puisqu'il leur faut de la déduplication, de la revalidation et de l'invalidation, et rien de tout ça n'est de la gestion d'état, c'est du cache. Tout ce qu'un utilisateur pourrait vouloir mettre en lien ou retrouver après un rafraîchissement, comme les filtres ou l'onglet ouvert, va dans l'URL. Tout ce qu'un seul composant possède reste dans useState. Le Context, je m'en sers pour les choses stables : le thème, l'utilisateur connecté, une instance de client, parce qu'il n'a pas de sélecteurs et que les mises à jour fréquentes y coûtent cher. Ce qui reste est de l'état client réellement global, comme un éditeur multi-panneaux avec un annuler partagé, et c'est là que j'amène un store. Je penche pour un petit store à sélecteurs basés sur des hooks plutôt que Redux sur un nouveau projet, mais si une équipe connaît déjà Redux Toolkit et a les réflexes devtools, la cohérence bat ma préférence à tous les coups.