Comment décidez-vous où doit vivre un morceau d'état donné ?

Commencez aussi local que possible, dans le composant qui l'utilise, et ne le remontez au plus proche ancêtre commun que si des frères ont réellement besoin de le partager. Si ce sont des données serveur, elles appartiennent à une couche de cache, pas à l'état d'un composant. Si un utilisateur doit pouvoir en faire un lien, comme des filtres ou l'onglet courant, mettez-le dans l'URL. Un store global est le dernier recours.

Mon premier réflexe, c'est de déterminer de quelle sorte d'état il s'agit, parce que la plupart des choses que les gens appellent état ne sont pas vraiment de l'état local. Si ça vient du serveur, ça va dans un cache de requêtes, comme ça j'ai la déduplication, la revalidation et la gestion de la péremption au lieu de bricoler tout ça dans un useState et un effet. Si ça doit survivre à un rafraîchissement ou se partager sous forme de lien, comme les filtres actifs ou l'onglet ouvert, ça va dans l'URL. Ce qui reste est du vrai état d'interface, et ça commence dans le composant qui l'utilise. Je ne remonte que quand un deuxième composant en a réellement besoin, et seulement jusqu'au parent commun le plus proche. Les stores globaux, je les garde pour les choses vraiment transversales, comme l'utilisateur courant ou une connexion websocket. Le problème que j'ai nettoyé le plus souvent, c'est un état remonté dans un provider de haut niveau parce que deux composants en avaient besoin une fois, et deux ans plus tard tout se re-rend à chaque frappe et plus personne n'ose le redescendre.