Accueil / Articles / La vitesse de réaction commence par l’organisation de l’arbre des composants.

react performance architecture state frontend rendering

La vitesse de réaction commence par l’organisation de l’arbre des composants.

Les re-rendus ne sont pas l’ennemi : c’est la propagation étendue à l’échelle de l’état qui l’est. Déplacez les sources vers le niveau le plus bas avant d’effectuer du micro-mémorisation.

1699 mots

React fait ce que le modèle en arbre exige. Lorsqu’une application semble lente, c’est souvent parce que le framework suit un chemin de propagation des états/mises à jour trop long, et non pas parce qu’il fonctionne de manière mystérieuse.

Le re-rendering n’est pas l’ennemi

Les rendus permettent à l’interface utilisateur de rester cohérente. L’ennemi, c’est le travail inutile effectué sur de grands sous-arbres à chaque frappe.

// ❌ count lives in Parent — expensive siblings re-render on every click
function Parent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>Count: {count}</button>
      <ExpensiveComponent />
      <AnotherExpensiveComponent />
    </div>
  );
}

// ✅ count lives in Counter — expensive siblings are untouched
function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(c => c + 1)}>
      Count: {count}
    </button>
  );
}

function Parent() {
  return (
    <div>
      <Counter />
      <ExpensiveComponent />
      <AnotherExpensiveComponent />
    </div>
  );
}

// ❌ SearchLayout owns state — ExpensiveList re-renders on every keystroke
function SearchLayout() {
  const [query, setQuery] = useState('');

  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      <ExpensiveList />
    </div>
  );
}

/* ✅ StatefulInput receives expensive content as children
 — its reference stays stable */
function StatefulInput({ children }) {
  const [query, setQuery] = useState('');
  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      {children}
    </div>
  );
}

function SearchLayout() {
  return (
    <StatefulInput>
      <ExpensiveList />
    </StatefulInput>
  );
}

Où la propagation doit s’arrêter

Déplacer la source

Placer les états à côté des composants qui les écrivent et les lisent. Le texte provisoire d’un formulaire n’a pas besoin d’être stocké à la racine de l’application.

Bloquer le chemin

Les enfants qui reçoivent des props stables peuvent éviter ce problème. La composition et l’utilisation d’enfants en tant que slots sont souvent plus efficaces qu’une mise en mémoire globale.

L’arbre comme décision de conception

L’organisation est un choix architectural : les dossiers de fonctionnalités, la séparation entre conteneurs et éléments présentationnels, ainsi que les fournisseurs locaux limitent l’impact des mises à jour.

Partir de l’arbre

Analysez d’abord, puis réorganisez ; mémorisez en dernier.

Les fournisseurs de contexte font partie de l’arbre : un méga-contexte qui change à chaque rendu annule l’effet de mémorisation des feuilles. Séparez les contextes en fonction de leur fréquence de mise à jour.

La segmentation du code au niveau des routes réduit l’arbre dont vous avez besoin pour la première affichage ; combinez-la avec l’état local pour garder les navigations légères.

La virtualisation des listes revient à une intervention chirurgicale sur l’arbre : désactivez les lignes hors écran plutôt que de gérer des milliers de nœuds inactifs.

Propriété du document : quelle équipe est responsable de l’état de chaque sous-arbre. Les stores globaux partagés récréent le problème de propagation étendue sous un nom différent.