Explication de la rendu React : mises à jour de l’état vers les pixels de l’écran

Lorsque l’on travaille avec React, on entend souvent l’expression « le composant a été rérendu ». Mais qu’est-ce que le rendu signifie réellement en arrière-plan ?

Plusieurs questions naturelles se posent alors. React envoie-t-il des mises à jour au DOM dès que l’état change ? Un changement d’état force-t-il chaque composant à être rérendu ? Et lorsque React rérend une élément, cela signifie-t-il que le navigateur redessine immédiatement toute la page ? Il s’avère que rien de tout cela n’est vrai.

Pour vraiment comprendre le cycle de vie du rendu, il faut saisir deux systèmes distincts qui fonctionnent ensemble :

Le cycle de vie de rendu propre à React, et le pipeline de rendu du navigateur.

Dès que vous comprenez comment ces deux systèmes sont connectés, des concepts tels que la réconciliation, la phase d’inscription, useEffect, useLayoutEffect, le re-rendering et la mémorisation cessent de sembler magiques pour devenir logiques.

1. La vue d’ensemble

À un niveau général, le flux est le suivant :

User Interaction
      │
      ▼
State / Props Change
      │
      ▼
┌──────────────────────┐
│     React Render     │
│                      │
│  Component executes  │
│  New UI is returned  │
└──────────┬───────────┘
           │
           ▼
     Reconciliation
           │
           ▼
┌──────────────────────┐
│     Commit Phase     │
│                      │
│  Update real DOM     │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────────┐
│    Browser Rendering     │
│                          │
│ Style → Layout → Paint   │
│           → Composite    │
└────────────┬─────────────┘
             │
             ▼
           Screen

Le point essentiel à retenir est le suivant :

React détermine à quoi doit ressembler l’interface utilisateur et quels changements dans le DOM sont nécessaires. Le navigateur prend ensuite ces modifications du DOM et les transforme en pixels réels à l’écran.

2. Que signifie « Rendering » ?

Le terme rendering est utilisé dans plusieurs sens.

Dans le contexte de React, rendering signifie généralement ceci :

React appelle la fonction de votre composant et détermine à quoi doit ressembler l’interface utilisateur résultante.

Considérez ce composant :

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button>
      Count: {count}
    </button>
  );
}

Lorsque React le rend, le corps de la fonction s’exécute :

Counter()
   ↓
returns React element
   ↓
<button>Count: 0</button>

Cela ne signifie pas pour autant que le navigateur a déjà affiché le bouton à l’écran.

Au préalable de tout élément visuel, React doit encore déterminer si le DOM réel a vraiment besoin d’être modifié.

En bref :

React Render
     ≠
DOM Update
     ≠
Browser Paint

Le rendu et la mise à jour du DOM sont deux opérations distinctes.

3. Cycle de rendu du navigateur

Imaginons que vous ayez ce markup :

<h1 class="title">
  Hello World
</h1>

Accompagné de cette feuille de style :

.title {
  color: red;
  font-size: 30px;
}

Avant que ce contenu ne soit affiché visuellement, le navigateur effectue une série d’étapes internes.

Une version simplifiée de ce processus se présente comme suit :

HTML
 ↓
DOM
 ↓
CSS
 ↓
CSSOM
 ↓
Render Tree
 ↓
Layout
 ↓
Paint
 ↓
Composite
 ↓
Screen

Examinons chaque étape en détail.

4. HTML → DOM

Le navigateur lit l’HTML et crée le DOM, pour Document Object Model.

Avec ce marquage :

<body>
  <h1>Hello World</h1>
  <p>Welcome</p>
</body>

Le navigateur construit une structure en arbre à peu près comme ceci :

Document
   │
   └── body
       ├── h1
       │   └── "Hello World"
       │
       └── p
           └── "Welcome"

JavaScript peut alors interroger et manipuler directement cette structure :

document.querySelector("h1");

En essence, le DOM répond à une seule question :

Quels éléments existent sur la page ?

5. CSS → CSSOM

En plus du DOM, le navigateur analyse également votre CSS et crée le CSSOM, ou CSS Object Model.

Par exemple :

h1 {
  color: red;
  font-size: 30px;
}

À partir de cela, le navigateur détermine quels styles s’appliquent à quels éléments.

Conceptuellement, c’est représenté comme suit :

h1
 ├── color: red
 └── font-size: 30px

Le CSSOM répond à une question différente :

Comment chaque élément doit-il être stylisé visuellement ?

6. DOM + CSSOM → Arbre de rendu

Ensuite, le navigateur fusionne le DOM et le CSSOM pour créer un arbre de rendu.

Il y a une subtilité à noter :

Tous les nœuds du DOM ne sont pas représentés dans l’arbre de rendu.

Prenons par exemple ce markup :

<div class="hidden">
  Hello
</div>

En combinaison avec cette règle :

.hidden {
  display: none;
}

L’élément div est présent dans le DOM :

DOM
 └── div

Mais comme il contient :

display: none;

il est complètement exclu de l’arbre de rendu visuel.

7. Mise en page

Lorsque le navigateur sait exactement quels éléments doivent être affichés, il détermine leur géométrie.

Cela implique le calcul de éléments tels que :

• Largeur
• Hauteur
• Position
• Marges
• Espace interne
• Coordonnées
• La relation spatiale entre les éléments

Prenons cette règle comme exemple :

.box {
  width: 200px;
  height: 100px;
  margin-left: 50px;
}

Le navigateur doit produire des valeurs concrètes de ce type :

x      = 50px
y      = ...
width  = 200px
height = 100px

Cette étape de calcul est appelée Layout, et elle est également souvent désignée sous le nom de Reflow.

8. Paint

Lorsque le layout est terminé, le navigateur dispose des coordonnées de chaque élément visible.

L’étape suivante consiste à dessiner l’apparence réelle de ces éléments.

Considérez ce style :

.box {
  background: blue;
  color: white;
  border: 2px solid black;
}

Le processus de Paint comprend des éléments tels que :

• Arrière-plan
• Texte
• Bordures
• Ombres
• Images
• Autres éléments visuels

En séquence :

Layout
  ↓
Paint
  ↓
Pixels

9. Composite

Les navigateurs actuels peuvent diviser une page en plusieurs couches distinctes.

Par exemple :

Layer 1 → Page background
Layer 2 → Header
Layer 3 → Content
Layer 4 → Modal

Le composant du navigateur fusionne ensuite toutes ces couches en une seule image qui apparaît à l’écran.

Certaines propriétés CSS, comme :

transform
opacity

Il est généralement possible de l’animer uniquement par composition, en évitant ainsi le travail de mise en page plus complexe requis par les propriétés affectant la géométrie.

C’est en partie pour cette raison que l’animation de transform est souvent la méthode préférée.

10. Cycle de rendu de React

Puisque le côté navigateur a été abordé, examinons maintenant la manière dont React gère le rendu.

1. Trigger
2. Render
3. Reconciliation
4. Commit
5. Browser Rendering

Examinons chacune d’elles.

11. Phase 1 — Déclencheur

Au préalable, React a besoin d’un signal indiquant :

"L’interface utilisateur pourrait nécessiter une mise à jour."

Ce signal est appelé déclencheur de rendu.

Les déclencheurs typiques incluent :

1. Mise à jour de l’état : setCount(10);

2. Modification des props : <Child count={count} />

Lorsqu’un composant parent se rérend avec une nouvelle valeur pour count, ses enfants peuvent ainsi recevoir de nouvelles propriétés.

3. Mise à jour du contexte : useContext(MyContext);

Chaque fois que la valeur lue dans le contexte change, les composants qui l’utilisent peuvent avoir besoin d’être mis à jour.

4. Mise à jour d’un stock externe : Les bibliothèques et les API peuvent également déclencher des mises à jour de React.

Les exemples incluent :

Redux
Zustand
useSyncExternalStore

Le montage d’une application pour la première fois compte également comme un déclencheur.

12. Phase 2 — Rendu

Dès que React détecte une mise à jour, il passe à la phase de rendu, où il exécute les composants afin de déterminer la nouvelle interface utilisateur.

Prenons cet exemple :

function Counter() {
  const [count, setCount] = useState(0);

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

Au début, count vaut 0. React appelle Counter() et produit :

<button>
  Count: 0
</button>

Lorsque le bouton est cliqué et que ce code s’exécute :

setCount(c => c + 1);

count devient 1, et React réexécute le composant, ce qui donne :

<button>
  Count: 1
</button>

13. Important : Le rendu ne signifie pas à proprement parler une mise à jour du DOM

C’est une distinction cruciale dans le modèle de React.

Lorsque React exécute cette fonction :

function Counter() {
  console.log("Counter rendered");

  return <button>Count: 1</button>;
}

il se contente de calculer à quoi l’interface utilisateur devrait ressembler. Cela ne signifie pas automatiquement que le DOM a changé ou que le navigateur a redessiné quoi que ce soit.

La véritable séquence est la suivante :

Component executes
       ↓
React creates new element representation
       ↓
Reconciliation
       ↓
Determine required DOM changes
       ↓
Commit changes

Cela mène à une règle fondamentale :

Rendre un composant ne se traduit pas automatiquement par une mise à jour du DOM.

14. Phase 3 — Réconciliation

À ce stade, React compare l’interface utilisateur ancienne et la nouvelle pour déterminer précisément ce qui a changé.

Disons que l’arborescence précédente ressemblait à :

button
 └── "Count: 0"

Et que l’arborescence nouvelle ressemble à :

button
 └── "Count: 1"

React peut déterminer :

button → same
text   → changed

Il n’a donc besoin de modifier que la partie du DOM qui a réellement changé :

button.textContent = "Count: 1";

L’objectif principal est d’éviter de démanteler et de reconstruire tout l’arbre DOM lorsque seules de petites parties ont changé.

15. Clés et réconciliation

Les clés sont particulièrement importantes lorsque React traite des listes.

Par exemple :

items.map(item => (
  <li key={item.id}>
    {item.name}
  </li>
))

React s’appuie sur les clés pour suivre quel élément correspond à quoi entre différentes rendus. Supposons que vous commenciez avec :

Before:

A
B
C

et que vous arriviez à :

After:

A
C

Avec des clés stables, React peut inférer correctement :

A → same
B → removed
C → same

Cela fournit à React des informations bien plus fiables sur lesquelles s’appuyer lors de la réconciliation.

Évitez de vous fier aux indices d’array en tant que clés lorsque les éléments de liste pourraient être réordonnés, ajoutés ou supprimés.

16. Phase 4 — Validation

Lorsque React a déterminé ce qui doit être modifié, il passe à la phase d’application, où ces modifications sont réellement appliquées au DOM réel.

Imaginez un élément bouton dont l’étiquette passe d’une valeur zéro à une valeur un une fois cette phase terminée.

À ce stade, l’arbre interne de React et le DOM en temps réel coïncident enfin.

La phase d’application est une étape distincte de la phase de rendu :

Render Phase
    ↓
Calculate what should change

Commit Phase
    ↓
Actually apply DOM changes

17. Phase de rendu vs phase d’application

Comprendre cette distinction fait partie des sujets les plus fréquemment abordés lors des entretiens.

Phase de rendu

Pendant cette phase, React :

• Exécute les fonctions des composants
• Détermine la prochaine version de l’interface utilisateur
• Effectue la réconciliation
• Découvre ce qui doit être modifié

Component
   ↓
React elements
   ↓
Reconciliation

Phase d’application

Pendant cette phase, React :

• Applique les mutations réelles du DOM
• Mise à jour de tous les référentiels
• Exécution des effets de mise en page liés à cette mise à jour

React result
    ↓
Real DOM

Voici une représentation simplifiée du flux :

             React
               │
               ▼
        ┌──────────────┐
        │ Render Phase │
        └──────┬───────┘
               │
               ▼
        ┌───────────────┐
        │ Commit Phase  │
        └──────┬────────┘
               │
               ▼
            Real DOM

18. Que se passe-t-il après l’envoi du commit ?

Lorsque la phase d’envoi du commit est terminée, le navigateur prend le relais et constate que le DOM a changé.

En fonction de ce qui a changé, le navigateur peut devoir effectuer plusieurs étapes :

DOM Changes
    ↓
Style Calculation
    ↓
Layout
    ↓
Paint
    ↓
Composite

Chaque modification n’exige pas l’ensemble de ces étapes pour produire un résultat significatif — une modification peut nécessiter uniquement une mise à jour visuelle, par exemple, sans avoir besoin d’un rec calcul complet de la mise en page.

C’est précisément à ce stade que le cycle de vie propre à React transfère la responsabilité au pipeline de rendu du navigateur décrit précédemment.

19. useLayoutEffect

useLayoutEffect s’exécute après que React ait enregistré ses mises à jour du DOM, mais avant que le navigateur n’ait l’occasion de redessiner les éléments nouveaux.

La séquence est la suivante :

React Render
     ↓
Commit
     ↓
DOM updated
     ↓
useLayoutEffect
     ↓
Browser Paint

function Tooltip() {
  const ref = useRef(null);

  useLayoutEffect(() => {
    const rect = ref.current.getBoundingClientRect();

    console.log(rect.width);
  }, []);

  return (
    <div ref={ref}>
      Tooltip
    </div>
  );
}

Cet hook est l’outil idéal lorsque vous avez besoin de :

• Mesurer les éléments dans le DOM
• Lire les valeurs de mise en page actuelles
• Appliquer des ajustements visuels de manière synchrone, avant que l’utilisateur ne voie quoi que ce soit

Une précaution : si les opérations à l’intérieur de useLayoutEffect sont lourdes, elles peuvent retarder le redessin et rendre l’interface utilisateur lente.

20. useEffect

useEffect, en revanche, est conçu pour les effets qui n’ont pas besoin de bloquer le redessin du navigateur.

useEffect(() => {
  fetch("/api/products");
}, []);

Render
   ↓
Commit
   ↓
Browser Paint
   ↓
useEffect

Les détails précis de planification sont un peu plus subtils que cela, mais la règle pratique fondamentale est :

Utilisez useLayoutEffect uniquement lorsque quelque chose doit se produire avant que le navigateur ne redessine l’interface ; utilisez useEffect pour tout ce qui peut être exécuté après que l’UI soit déjà visible.

21. Exemple complet

import { useEffect, useLayoutEffect, useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  console.log("Render");

  useLayoutEffect(() => {
    console.log("Layout Effect");
  });

  useEffect(() => {
    console.log("Effect");
  });

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

Conceptuellement, la séquence des événements se présente comme suit :

User clicks button
        ↓
setCount()
        ↓
State update scheduled
        ↓
Counter() executes
        ↓
"Render"
        ↓
React reconciles
        ↓
React commits DOM update
        ↓
"Layout Effect"
        ↓
Browser paints updated UI
        ↓
"Effect"

22. Un re-render du parent provoque-t-il un re-render de l’enfant ?

Prenons cet exemple :

function Parent() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>
        {count}
      </button>

      <Child />
    </>
  );
}

Lorsque count est mis à jour :

Parent renders
       ↓
Child is encountered
       ↓
Child may render as part of reconciliation

So,

Parent state update
      ↓
Parent render
      ↓
Child can render

Ce comportement explique en partie pourquoi React.memo existe en tant qu’outil d’optimisation.

23. React.memo

Supposons que vous ayez :

const Child = React.memo(function Child() {
  console.log("Child rendered");

  return <p>Hello</p>;
});

Si le parent se re-render mais que les props transmises à l’enfant restent identiques sur le plan référentiel, React peut éviter complètement de re-render cet enfant mémorisé.

Voici l’idée de manière visuelle :

Parent update
     ↓
Parent renders
     ↓
React.memo checks Child props
     ↓
Props unchanged
     ↓
Skip Child render

N’oubliez pas cependant :

React.memo vous offre un raccourci de performance — il ne garantit pas pour autant qu’un composant ne sera jamais rendu à nouveau.

Les changements de contexte, l’état interne et d’autres déclencheurs peuvent encore le forcer à s’actualiser, indépendamment de la mémorisation.

24. useMemo et useCallback

Ces deux hooks sont souvent mal compris.

useMemo : Il mémorise une valeur calculée.

const result = useMemo(() => expensiveCalculation(data), [data]);

useCallback : Il mémorise une référence de fonction.

const handleClick = useCallback(() => {
  doSomething(id);
}, [id]);

Tous deux sont véritablement utiles dans les situations où l’égalité de référence est importante pour éviter des tâches répétées — notamment lors du passage de props à des composants enfants mémorisés.

Néanmoins, les utiliser partout par défaut a tendance à ajouter de la complexité à votre code sans apporter d’amélioration réelle en termes de performance.

25. Un rendu React n’est pas identique à une mise en page par le navigateur

Ce point mérite d’être souligné explicitement.

Imaginons le composant suivant :

function App() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>
        {count}
      </button>

      <p>Hello</p>
    </div>
  );
}

Lorsque count change :

App renders
     ↓
New React tree created
     ↓
Reconciliation
     ↓
Only count text differs
     ↓
Commit small DOM update
     ↓
Browser rendering

React ne reconstruira pas nécessairement ce markup à partir de zéro :

<div>
  <button>...</button>
  <p>Hello</p>
</div>

26. Virtual DOM — Comprendre correctement le modèle conceptuel

On affirme souvent que React s’appuie sur un Virtual DOM pour accélérer le navigateur. C’est une simplification excessive.

En réalité, React conserve en mémoire une description interne de l’interface utilisateur et utilise la réconciliation pour déterminer ce qui a changé.

Le navigateur lui-même ne connaît pas le concept de Virtual DOM. Il ne travaille qu’avec des éléments tels que l’HTML, le DOM, le CSS et, en fin de compte, les pixels.

Conceptuellement, le flux est le suivant :

React Component
      ↓
React Element Tree
      ↓
Reconciliation
      ↓
DOM Mutations
      ↓
Browser
      ↓
Pixels

Le Virtual DOM n’est jamais quelque chose que le navigateur rend réellement.

27. Re-render vs Repaint

Ces deux concepts sont distincts et ne doivent pas être confondus.

Re-render dans React

C’est le moment où la fonction d’un composant s’exécute à nouveau — en d’autres termes, Component() est appelé.

Repaint par le navigateur

C’est lorsque le navigateur redessine les pixels à l’écran en raison d’un changement dans une propriété visuelle — c’est l’étape de Paint.

N’oubliez pas : un re-render dans React n’est pas équivalent à un repaint par le navigateur.

Il est tout à fait possible qu’un composant soit rendu à nouveau tout en produisant une structure DOM identique. Inversement, le navigateur peut effectuer un repaint pour des raisons qui n’ont rien à voir avec le rendu d’un composant React.

28. Reflow vs Repaint

Prenons cet exemple : element.style.width = "500px";

Changer la largeur d’un élément force généralement un rec calcul du layout :

Style
 ↓
Layout
 ↓
Paint
 ↓
Composite

Comparons maintenant avec : element.style.backgroundColor = "red";

Ici, le navigateur n’a généralement pas besoin de refaire les calculs géométriques :

Style
 ↓
Paint
 ↓
Composite

Et pour certaines modifications de transformation ou d’opacité, le navigateur n’a peut-être besoin que de :

Composite

Comprendre cette différence est très important lorsque l’on optimise des animations ou des interfaces nécessitant beaucoup de rendu.

29. Application à un scénario réel avec React

Imaginons une page de produit typique pour e-commerce structurée comme suit :

Product Page
 ├── Navbar
 ├── Product Gallery
 ├── Product Information
 ├── Add To Cart
 ├── Reviews
 └── Recommendations

Supposons qu’un utilisateur clique sur le bouton Ajouter au panier, ce qui met à jour le compteur du panier.

Conceptuellement, la séquence d’événements pourrait ressembler à ceci :

User clicks "Add to Cart"
           ↓
Cart state updates
           ↓
React schedules update
           ↓
Relevant components render
           ↓
React reconciles new tree
           ↓
Only required DOM changes are committed
           ↓
Browser performs necessary rendering work
           ↓
Updated cart count appears

Dans une application bien structurée, cette mise à jour du compteur de panier ne devrait pas forcer la reconstruction inutile de toute l’interface utilisateur. C’est précisément pour cette raison que les décisions concernant les limites des composants, l’emplacement de l’état, la mémorisation et l’architecture globale de rendu revêtent une grande importance.

30. Lorsque le rendu coûteux devient un problème de performance

function ProductList({ products }) {
  return products.map(product => (
    <ExpensiveProductCard
      key={product.id}
      product={product}
    />
  ));
}

Supposons que cette liste affiche 10 000 produits, et qu’un changement d’état non lié déclenche des opérations inutiles dans un grand nombre de composants — la performance peut se dégrader de manière significative.

Les techniques d’atténuation courantes incluent :

React.memo
      +
Stable props
      +
useMemo/useCallback where justified
      +
Virtualization
      +
Pagination
      +
Code splitting

Pour des listes particulièrement longues, la virtualisation s’avère souvent particulièrement efficace :

10000 items
     ↓
Only visible ~20-50 items rendered

31. Comment le rendu interagit avec React concurrent

Les versions plus récentes de React intègrent des capacités de planification plus avancées. React peut attribuer une priorité aux différentes mises à jour et, le cas échéant, suspendre ou reporter les tâches de rendu.

Le modèle mental essentiel à retenir est :

Render work
    ↓
Can be scheduled
    ↓
Can be interrupted in modern React
    ↓
Eventually committed

C’est précisément pour cette raison que les effets secondaires ne devraient pas figurer dans la logique de rendu d’un composant :

function Component() {
  fetch("/api/data"); // ❌ Side effect during render

  return <div>Hello</div>;
}

Préférez plutôt utiliser un hook effect ou un schéma adapté de récupération de données. Idéalement, la phase de rendu doit rester pure.

32. Les avantages d’un rendu pur

Conceptuellement, un composant React doit se comporter comme une fonction pure :

UI = f(props, state)

Avec les mêmes props et état, il doit toujours représenter le même interface utilisateur. Par exemple :

function Greeting({ name }) {
  return <h1>Hello {name}</h1>;
}

Ce comportement est prévisible et sûr.

En revanche, effectuer une telle action à l’intérieur de la fonction render pose problème :

function Component() {
  localStorage.setItem("x", "1"); // ❌
  fetch("/api");                  // ❌

  return <div>Hello</div>;
}

Cela introduit des effets secondaires dans une phase que React pourrait exécuter plus d’une fois ou planifier de manières inattendues.

Les effets secondaires doivent être placés ailleurs — à l’intérieur des effets, des gestionnaires d’événements ou des mécanismes de récupération de données fournis par votre framework.

33. Cycle de vie du rendu — Modèle mental complet

                    USER ACTION
                         │
                         ▼
               State / Props Update
                         │
                         ▼
                React Schedules Work
                         │
                         ▼
                 ┌──────────────┐
                 │    RENDER    │
                 │              │
                 │ Components   │
                 │ execute      │
                 └──────┬───────┘
                        │
                        ▼
                 Reconciliation
                        │
                        ▼
                 ┌──────────────┐
                 │    COMMIT    │
                 │              │
                 │ DOM mutation │
                 └──────┬───────┘
                        │
                        ▼
                 useLayoutEffect
                        │
                        ▼
              Browser Rendering
                        │
                        ▼
                 Style Calculation
                        │
                        ▼
                     Layout
                        │
                        ▼
                      Paint
                        │
                        ▼
                   Composite
                        │
                        ▼
                      SCREEN
                        │
                        ▼
                   useEffect

Questions d’entretien courantes

Q1. Une mise à jour d’état met-elle immédiatement à jour le DOM ?

Non. Une mise à jour d’état ne fait que planifier des tâches à effectuer par React. React rend la composante, compare le résultat avec ce qui était affiché précédemment, et n’applique les modifications du DOM nécessaires qu’à ce moment-là.

setState
  ↓
Render
  ↓
Reconciliation
  ↓
Commit
  ↓
DOM

Q2. Chaque rendu entraîne-t-il une mise à jour du DOM ?

Non. React peut rendre une composante et conclure que la description de l’interface résultante est identique à celle qui est déjà affichée à l’écran ; dans ce cas, il évite de modifier le DOM.

Render
  ↓
Compare
  ↓
No meaningful DOM difference
  ↓
No DOM mutation

Q3. Le rérendu dans React force-t-il le navigateur à redessiner ?

Non. Le rendu dans React et le dessin dans le navigateur sont deux processus indépendants.

React Render ≠ Browser Paint

Q4. Que signifie la réconciliation ?

La réconciliation consiste en ce que React compare l’arbre UI fraîchement calculé à celui précédent afin de déterminer exactement ce qui doit changer.

Q5. Que se passe-t-il pendant la phase de commit ?

Pendant le commit, React applique les modifications nécessaires à l’environnement hôte — par exemple, en mettant à jour les nœuds DOM réels dans un navigateur.

Q6. En quoi useEffect et useLayoutEffect diffèrent-ils ?

Une façon simple de s’en souvenir :

useLayoutEffect
→ after DOM commit, before paint

useEffect
→ after commit and generally after paint

Utilisez useLayoutEffect lorsque vous devez mesurer ou ajuster le layout de manière synchrone avant que l’utilisateur ne voie la nouvelle frame. Utilisez useEffect pour la plupart des effets secondaires qui n’ont pas besoin de bloquer le rendu.

Q7. Qu’est-ce qui déclenche le rendu d’un composant ?

Les déclencheurs typiques sont : un montage initial, une mise à jour d’état, un rérendu d’un parent, un changement de props, une mise à jour du contexte, ou une mise à jour provenant d’un stock externe.

Q8. Comment optimiser le rendu ? [IMP]

Au lieu d’utiliser useMemo partout par défaut, identifiez d’abord où se trouve le véritable goulot d’étranglement. Ensuite, envisagez ces approches :

1. Conservez l’état près de l’endroit où il est utilisé

Évitez une structure où l’état se trouve en haut et où chaque descendant dépend de lui :

App
 ↓
Everything depends on state

prefer:

Feature
 ↓
Local state

Préférer une emplacement plus restreint lorsque l’état global n’est pas vraiment nécessaire.

2. Mémoriser sélectivement les composants coûteux

const ProductCard = React.memo(ProductCardComponent);

3. Faire attention à la création d’objets qui perturbent la mémorisation

Au lieu de créer à chaque fois un nouvel objet en ligne comme ceci :

<Child config={{ theme: "dark" }} />

vous pourriez avoir besoin d’une référence stable si Child est enveloppé dans React.memo et que l’identité compte — mais ne résolvez ce problème qu’en cas de véritable difficulté.

4. Virtualiser les listes longues

Au lieu de rendre tous les 10 000 nœuds DOM en même temps, ne rendez que ceux qui sont actuellement visibles.

5. Reporter le chargement des fonctionnalités coûteuses

const AdminDashboard = lazy(() => import("./AdminDashboard"));

Cela réduit la quantité de JavaScript qui doit être téléchargée et exécutée au préalable.

6. Privilégier des techniques de rendu compatibles avec le navigateur

Animez avec des propriétés peu coûteuses telles que transform et opacité lorsque c’est possible, et évitez de forcer des recalculs de mise en page coûteux à chaque frame.

Lectures complémentaires