Quelles sont les caractéristiques de performance du React Context, et comment l'empêchez-vous de refaire le rendu de la moitié de l'application ?

Chaque consommateur refait son rendu quand la valeur du provider change par référence, quelle que soit la partie de la valeur qu'il lit, parce que le contexte n'a pas de sélecteur. Un provider qui tient un gros objet reconstruit à chaque rendu va donc faire re-rendre tous les consommateurs en permanence. On corrige en mémoïsant la valeur, en séparant l'état et le dispatch dans deux contextes distincts, ou en plaçant les données dans un store externe auquel les consommateurs s'abonnent avec des sélecteurs.

Le contexte est d'abord un mécanisme d'injection de dépendances, et un gestionnaire d'état très loin derrière. Le problème de performance, c'est que les consommateurs s'abonnent à la valeur entière, donc dès que la valeur du provider change d'identité, tous les consommateurs en dessous se rendent, même celui qui ne lit qu'un seul booléen. La première chose que je vérifie, c'est si le provider construit un nouvel objet en ligne dans le JSX, parce que c'est une nouvelle référence à chaque rendu du parent et ça annule tout le reste. Ensuite je sépare les contextes, parce qu'en général les données changent souvent et les setters ne changent jamais, donc mettre le dispatch dans son propre contexte coupe l'essentiel du bruit. S'il me faut encore des sélecteurs, j'arrête de faire semblant que le contexte est un store et je mets l'état dans un vrai store, puis je m'abonne avec useSyncExternalStore ou une bibliothèque pour que chaque composant prenne sa tranche. Là où le contexte reste excellent, c'est pour les choses stables : le thème, l'utilisateur courant, une locale, une instance de client. Ça ne change quasiment jamais, donc le coût de re-rendu n'a aucune importance.