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.
Wie React alte und neue Fiber-Bäume vergleicht, um Aktualisierungen, Einfügungen oder Löschungen zu bestimmen.
Reconciliation ist Reacts Algorithmus zur effizienten Aktualisierung der Benutzeroberfläche, wenn sich Zustand oder Props ändern. Anstatt den gesamten DOM-Baum neu zu rendern, vergleicht React den vorherigen virtuellen DOM-Baum mit dem neu gerenderten Baum und berechnet die minimale Anzahl an benötigten Operationen. Es verwendet zwei Schlüsselheuristiken, um dies in O(n) statt O(n³) Zeit zu erreichen.
React nimmt an: (1) Elemente unterschiedlicher Typen erzeugen völlig verschiedene Bäume — daher hebt React den alten Teilbaum auf und mountet einen neuen. (2) Der Entwickler kann mithilfe der key-Prop stabile Identitäten über Renderings hinweg angeben.
Wenn zwei Elemente denselben Typ haben (z.B. beide <div>), behält React den vorhandenen DOM-Knoten und aktualisiert nur die geänderten Attribute/Props. Dies vermeidet das unnötige Zerstören und Neuerstellen von DOM-Knoten.
Wenn sich der Typ ändert (z.B. <div> wird zu <span>), hebt React den alten Komponentenbaum vollständig auf (führt alle Bereinigungen aus) und mountet den neuen Baum von Grund auf. Der Zustand geht verloren.
Für Listen von Kindern ordnet React alte und neue Elemente nach Key zu. Ohne Keys verwendet React die Position — was zu unnötigen Unmounts führen kann, wenn Elemente neu geordnet werden. Keys ermöglichen React, vorhandene DOM-Knoten effizient zu verschieben.
Während React beide Bäume durchläuft, erstellt es eine 'Effect-Liste' — eine verknüpfte Liste von Fibers, die Arbeit zu erledigen haben (Aktualisierungen, Einfügungen, Löschungen). Die Commit-Phase durchläuft diese Liste und wendet Änderungen auf das echte DOM an.
Eine Arbeitseinheit in Reacts Reconciliation-Modul. Jede Komponente hat einen Fiber-Knoten, der Typ, Props, Zustand und Zeiger auf Elternteil/Kind/Geschwister speichert.
Ein Klon des aktuellen Fiber-Baums, in dem React während der Reconciliation Änderungen vornimmt. Wird erst nach Abschluss der Commit-Phase zum 'current'.
Eine flache verknüpfte Liste von Fibers mit ausstehenden DOM-Mutationen, die während der Reconciliation aufgebaut und in der Commit-Phase durchlaufen wird.
Wenn React erkennt, dass sich Props und Kontext eines Fibers nicht geändert haben, kann es das Rendering dieses Teilbaums vollständig überspringen — eine wichtige Leistungsoptimierung.
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
Reconciliation macht Reacts deklaratives Modell praktikabel. Sie beschreiben, wie die Benutzeroberfläche aussehen soll, und React ermittelt die minimale Menge an DOM-Änderungen. Die Fiber-Architektur macht dies unterbrechbar — React kann die Reconciliation mitten im Baum pausieren und später fortsetzen, was Concurrent-Features wie Suspense und Transitions ermöglicht.
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.