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.
Regardez comment React parcourt l'arbre Fiber en profondeur pendant la réconciliation.
Fiber est le moteur de réconciliation interne de React, introduit dans React 16. Chaque composant de votre application possède un nœud Fiber correspondant — un objet JavaScript qui stocke le type du composant, ses props, son state, le nœud DOM associé, ainsi que des pointeurs vers les fibers parent, enfant et sibling. Cette structure chaînée permet à React de suspendre, reprendre et prioriser le travail sur plusieurs frames.
Lorsque React rend votre arbre de composants, il crée un nœud Fiber pour chaque élément. Le nœud stocke : le type (fonction/classe/chaîne), les props, le state, les hooks d'effet et le state en cours de travail issu du rendu précédent.
Contrairement à une pile d'appels récursive (qui ne peut pas être suspendue), les Fibers sont connectés en liste chaînée : chaque nœud possède un pointeur enfant (premier enfant), un pointeur sibling (sibling suivant) et un pointeur return (parent). Cela permet à React de parcourir l'arbre de manière itérative.
React parcourt l'arbre Fiber en profondeur. Il appelle 'beginWork' en descendant (parent → enfant) et 'completeWork' en remontant (enfant → parent). Cette approche en deux passes permet à React de construire une liste d'effets de bas en haut.
React maintient deux arbres Fiber simultanément : l'arbre 'current' (ce qui est affiché à l'écran) et l'arbre 'work-in-progress' (ce qui est en cours de construction). Chaque nœud Fiber possède un pointeur 'alternate' reliant son homologue dans l'autre arbre.
Lorsque la phase de commit se termine, React permute atomiquement les deux arbres en faisant pointer le pointeur 'current' de la racine vers l'arbre work-in-progress. L'ancien arbre current devient le nouveau work-in-progress pour le prochain rendu.
Un objet JS représentant une unité de travail pour un composant. Contient le type, la key, la ref, les props, le state, la liste des hooks, les tags d'effet et les pointeurs d'arbre.
L'arbre Fiber en cours de construction pendant la réconciliation. Non visible par l'utilisateur jusqu'à ce que la phase de commit se termine et qu'il soit échangé avec l'arbre current.
Les deux fonctions que React appelle lors du parcours de l'arbre Fiber. beginWork traite un nœud en descendant ; completeWork le finalise en remontant.
Un masque de bits sur un nœud Fiber indiquant le travail DOM à effectuer : Placement (insertion), Update (mise à jour des props), Deletion (suppression).
Chaque fiber possède un champ 'alternate' pointant vers son homologue dans l'autre arbre (current ↔ work-in-progress). Permet le double buffering.
1// Simplified Fiber node structure (React internals)2{3 tag: FunctionComponent, // type of fiber4 type: MyComponent, // component function/class/string5 key: null,6 ref: null,7 pendingProps: { id: 1 },8 memoizedProps: { id: 1 }, // props from last render9 memoizedState: hooksList, // linked list of hooks1011 // Tree pointers12 return: parentFiber, // parent13 child: firstChildFiber, // first child14 sibling: nextSiblingFiber, // next sibling1516 // Double buffering17 alternate: workInProgressFiber,1819 // Work tracking20 flags: Update | Passive, // effect tags21 lanes: DefaultLane, // priority22}
L'architecture Fiber est ce qui rend possibles les fonctionnalités concurrentes de React. Parce que le travail est représenté comme une structure de données (et non une pile d'appels), React peut suspendre la réconciliation à n'importe quel nœud Fiber, rendre le contrôle au navigateur pour des tâches hautement prioritaires comme les interactions utilisateur, et reprendre là où il s'était arrêté. C'est le fondement de Suspense, des transitions et du batching automatique.
Your dashboard app freezes for 200ms when a user opens a settings panel. React DevTools Profiler shows a long 'Render' phase but you can't identify which component is slow.
Without understanding Fiber, the profiler's flame graph (which shows fiber-by-fiber render times) looks like random colored bars. You don't know why some components are 're-rendered' when their props haven't changed.
Understanding that each bar in the Profiler IS a fiber node helps you trace the work loop: parent → child → sibling. You can identify which fiber's `beginWork` is slow, check its `memoizedProps` vs `pendingProps`, and apply React.memo or useMemo precisely.
Takeaway: The React DevTools Profiler is literally a fiber tree visualizer. Understanding fiber architecture transforms it from a confusing chart into a powerful debugging tool.
You have a drag-and-drop interface where moving an item should animate at 60fps, but data fetching from a heavy table re-render causes janky movement.
A single synchronous render blocks the main thread for 50ms+, causing the browser to skip animation frames during the data fetch re-render.
React Fiber's priority lanes system lets you wrap the heavy re-render in `startTransition()`, marking it as low-priority. The fiber work loop can now pause the heavy render, yield to the browser for animation frames, and resume later — all because fibers are interruptible units of work.
Takeaway: Fiber architecture is the reason `useTransition` and `useDeferredValue` exist. These APIs wouldn't be possible without interruptible, priority-based rendering.