Join the discussion
Comments
Loading comments...
Cookie preferences
We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.
Join the discussion
Loading comments...
We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.
Comment React compare les anciens et nouveaux arbres Fiber pour décider quoi mettre à jour, insérer ou supprimer.
La réconciliation est l'algorithme de React pour mettre à jour efficacement l'interface lorsque le state ou les props changent. Plutôt que de re-rendre l'intégralité de l'arbre DOM, React compare l'arbre DOM virtuel précédent avec l'arbre nouvellement rendu et calcule le nombre minimal d'opérations nécessaires. Il utilise deux heuristiques clés pour faire cela en temps O(n) au lieu de O(n³).
React suppose : (1) Les éléments de types différents produisent des arbres complètement différents — donc React démonte l'ancien sous-arbre et monte un nouveau. (2) Le développeur peut indiquer une identité stable entre les rendus grâce à la prop key.
Lorsque deux éléments ont le même type (p. ex. deux <div>), React conserve le nœud DOM existant et ne met à jour que les attributs/props modifiés. Cela évite de détruire et recréer inutilement des nœuds DOM.
Si le type change (p. ex. <div> devient <span>), React démonte entièrement l'ancien arbre de composants (en exécutant tous les nettoyages) et monte le nouvel arbre à neuf. Le state est perdu.
Pour les listes d'enfants, React fait correspondre les anciens et nouveaux éléments par key. Sans keys, React utilise la position — ce qui peut causer des démontages inutiles lors du réordonnancement. Les keys permettent à React de déplacer efficacement les nœuds DOM existants.
Lors du parcours des deux arbres par React, il construit une 'liste d'effets' — une liste chaînée de fibers qui ont du travail à faire (mises à jour, insertions, suppressions). La phase de commit parcourt cette liste et applique les changements au DOM réel.
Une unité de travail dans le moteur de réconciliation de React. Chaque composant possède un nœud Fiber stockant le type, les props, le state et des pointeurs vers les fibers parent/enfant/sibling.
Un clone de l'arbre Fiber current où React applique les changements pendant la réconciliation. Promu en 'current' seulement après la fin de la phase de commit.
Une liste chaînée plate de fibers avec des mutations DOM en attente, construite pendant la réconciliation et parcourue pendant la phase de commit.
Lorsque React détecte que les props et le contexte d'un fiber n'ont pas changé, il peut ignorer entièrement le rendu de ce sous-arbre — une optimisation de performance clé.
1// Without keys — position-based matching (bad for reordering)2// Old: [<A/>, <B/>, <C/>]3// New: [<B/>, <A/>, <C/>]4// React sees: position 0 changed (updates A→B), position 1 changed (updates B→A)5// Result: 2 updates + possible state loss67// With keys — identity-based matching (correct)8// Old: [<A key="a"/>, <B key="b"/>, <C key="c"/>]9// New: [<B key="b"/>, <A key="a"/>, <C key="c"/>]10// React sees: same keys, just reordered11// Result: 0 updates, 2 DOM moves — much more efficient
La réconciliation est ce qui rend le modèle déclaratif de React pratique. Vous décrivez à quoi l'interface devrait ressembler, et React détermine l'ensemble minimal de changements DOM nécessaires. L'architecture Fiber rend cela interruptible — React peut suspendre la réconciliation au milieu de l'arbre et la reprendre plus tard, permettant les fonctionnalités concurrentes comme Suspense et les transitions.
You have a todo list where users can delete items from the middle. Each item has an input field showing its text. After deleting the 2nd item, the 3rd item's input shows the 2nd item's text.
Using `index` as the key means when item 2 is deleted, React thinks item 3 IS item 2 (same key=2). It reuses the old component instance (with stale state) instead of destroying item 2 and moving item 3.
Use a stable unique ID (e.g., `todo.id`) as the key. Now React correctly identifies which component was removed and which should be kept. The reconciliation algorithm can match by identity instead of position.
Takeaway: The reconciliation algorithm's O(n) shortcut relies entirely on keys for list matching. Using array index as key defeats this optimization and introduces state bugs whenever order changes.
You have a conditional render: `isAdmin ? <AdminPanel /> : <UserPanel />`. Switching between admin and user views causes a full re-mount, destroying all form state.
React's reconciliation sees a different component TYPE at the same position. Its heuristic: 'different type = completely different tree'. It destroys the old subtree and builds a new one from scratch — losing all internal state.
If both panels share a similar structure, use the same component with conditional rendering inside. Or use `key` to explicitly control when a component should re-mount vs update. Understanding that React compares types first, then props, helps you design state-preserving UIs.
Takeaway: React's reconciliation compares elements top-down: type first, then key, then props. A type change always triggers a full unmount/remount of the entire subtree — this is by design, not a bug.