Im Inneren von React Fiber: Arbeitseinheiten, Render gegen Commit und Prioritätskanäle
Erfahren Sie, was React Fiber eigentlich ist, warum der alte Stack-Reconciler den Hauptthread blockierte und wie Arbeitseinheiten, zwei Phasen sowie Lanes eine parallele Darstellung ermöglichen.
„Fiber“ ist einer jener React-Begriffe, der weitaus öfter erwähnt wird, als er wirklich erklärt wird. Entwickler hören, dass es sich um einen neuen Engine handelt, ein Ersatz für den Virtual DOM oder etwas im Zusammenhang mit Hooks – doch keine dieser Beschreibungen ist ganz richtig. Diese Anleitung entwickelt das Konzept von Grund auf: Zuerst das Problem, mit dem React vor Version 16 zu kämpfen hatte, anschließend, was Fiber ist, wie das Rendering in zwei Phasen unterteilt wird und wie Scheduling und Prioritäten darauf aufbauen. Am Ende sollten Sie in der Lage sein, Fiber präzise zu erklären, gängige Missverständnisse zu erkennen und zu verstehen, warum APIs wie startTransition davon abhängen.
Fiber in einem Satz
React Fiber ist die interne Reconciliation-Architektur, die mit React 16 eingeführt wurde. Ihre Aufgabe besteht darin, den Render-Prozess steuerbar zu machen. Anstatt eine Aktualisierung als einzige, unteilbare Aufgabe zu behandeln, modelliert React die Arbeit in viele kleine Einheiten, die nacheinander verarbeitet und nach Bedeutung geordnet werden können.
Der Unterschied ist am leichtesten nebeneinander zu erkennen. Vor Fiber verlief eine Aktualisierung in einer geraden Linie von Anfang bis Ende:
Before Fiber:
Update
↓
Render entire tree
↓
Commit changes
↓
Done
Mit Fiber tritt eine Zwischenebene ein, in der die Arbeit in Teile zerlegt wird. Diese Teile können geordnet, pausiert und wieder aufgenommen werden, bevor irgendetwas auf dem Bildschirm angezeigt wird:
After Fiber:
Update
↓
Break work into units
↓
Process units
↓
Prioritize / pause / resume when appropriate
↓
Commit changes
Diese zusätzliche Ebene bildet die Grundlage für fast alle modernen Rendering-Funktionen in React. Um zu verstehen, warum eine Neuschreibung notwendig war, schauen Sie sich das vorherige Verhalten an.
Der Stack Reconciler und sein Blindpunkt
React-Versionen vor 16 verwendeten das, was üblicherweise als Stack Reconciler bezeichnet wird. Der gesamte Ablauf war bereits vertraut: Eine Zustandsänderung führt zu einer Renderung, diese wird mit dem vorherigen Ergebnis abgeglichen und anschließend wird der DOM aktualisiert.
State Change
↓
Render
↓
Reconciliation
↓
DOM Updates
Das Problem war, dass die Abgleichung synchron ablaufte. Der Name leitet sich davon ab, dass der Reconciler den Baum durch gewöhnliche rekursive Funktionsaufrufe durchlief, wodurch der Fortschritt der Arbeit direkt auf dem JavaScript-Callstack lag. Sobald React mit der Verarbeitung einer Aktualisierung begann, gab es keine natürliche Möglichkeit, sie mitten im Lauf zu stoppen – denn ein Stoppen würde bedeuten, diesen Stack rückgängig zu machen und den Fortschritt zu verlieren. Stellen Sie sich eine mittelgroße Anwendung vor:
App
│
├── Header
├── Sidebar
├── Dashboard
│ ├── Chart
│ ├── Table
│ └── Statistics
├── Notifications
└── Footer
Falls eine Aktualisierung einen großen Teil dieses Baums betrifft, würde React die betroffenen Komponenten in einer einzigen durchgehenden Durchlaufsequenz von der ersten bis zur letzten abarbeiten, ohne jemals die Kontrolle zurückzugeben:
Start rendering
↓
Component A
↓
Component B
↓
Component C
↓
Component D
↓
Component E
↓
...
↓
Finish
Die Ausgabe war in Ordnung; das Problem lag im Zeitbedarf. React konnte die Arbeit nicht unterbrechen und später wieder aufnehmen, sodass alles andere warten musste.
Warum ein langer Render den Benutzer beeinträchtigt
JavaScript verfügt nicht über einen eigenen Hauptthread. Der Browser verwendet denselben Thread, um Ereignishandler auszuführen, das Layout zu berechnen, Pixel darzustellen und Frames zu erzeugen:
Browser Main Thread
│
├── JavaScript
├── Event Handling
├── Layout
├── Paint
└── Rendering
Wenn ein Skript den Thread über einen längeren Zeitraum blockiert, warten alle anderen Aufgaben hinter ihm in der Warteschlange. Aus Sicht des Benutzers sieht die Abfolge der Ereignisse so aus:
Click
↓
React starts large update
↓
Main thread remains busy
↓
Browser can't respond quickly
↓
UI feels slow
Eine Klickaktion wird spät erfasst, eine Tastenbetätigung tritt mit einer bemerkbaren Verzögerung auf, eine Animation stockt. In einer kleinen Anwendung ist der Render-Vorgang so kurz, dass es niemand bemerkt. Wenn die Anwendung jedoch wächst und die Interaktionen zunehmen, benötigt ein Framework eine Kontrolle darüber, wann die Renderarbeiten ausgeführt werden und wie viel davon gleichzeitig abgewickelt wird. Genau diese Lücke soll Fiber schließen.
Die Kernidee: Arbeiten als planbare Einheiten
Das zugrundeliegende Konzept von Fiber lässt sich in einer einzigen Zeile zusammenfassen: Der Render-Vorgang wird in handhabbare Arbeitseinheiten aufgeteilt, die React planen und priorisieren kann.
Im alten Modell bestand die Anweisung an den Reconciler im Grunde aus einem einzigen Befehl:
"Render this entire tree."
Unter Fiber kann React hingegen einzelne Bestandteile berücksichtigen und entscheiden, welcher zuerst Aufmerksamkeit verdient:
"Here is one piece of work."
"Here is another piece."
"Which work should I process first?"
Durch diskrete Teile anstelle einer tiefen rekursiven Aufrufkette kann React nach jedem Teil aufhören, prüfen, ob es wichtigere Aufgaben gibt, und später fortfahren.
Was eine Fiber eigentlich ist
Eine Fiber ist ein einfaches JavaScript-Objekt, das eine Arbeitseinheit im internen Baum von React darstellt. In der Praxis gibt es in der Regel eine Fiber pro Komponente oder Element, das an der Abgleichsprozess teilnimmt. Schauen Sie sich diesen kleinen Komponentenbaum an:
App
│
├── Header
├── Sidebar
└── Content
Konzeptionell behält React eine aus Fibers bestehende parallele Struktur bei:
Fiber Tree
App Fiber
│
├── Header Fiber
├── Sidebar Fiber
└── Content Fiber
Reale Fiber-Objekte enthalten weitaus mehr als nur einen Namen. Sie speichern ihre Verbindungen zu Eltern-, Kind- und Geschwisterknoten, den Typ sowie die Identität der Komponente, ausstehende Props und Zustände sowie die Effekte, die ausgeführt werden müssen, sobald die Änderungen gespeichert sind. Genau diese expliziten Verbindungen ermöglichen es React, den Baum mit einer Schleife statt durch Rekursion zu durchlaufen – was wiederum das Anhalten und Wiederaufnehmen des Prozesses möglich macht. Für die gesamte Architektur reicht es jedoch aus, sich eine einzige Formel zu merken: Ein Fiber ist eine Einheit der Render- und Abgleichsarbeit von React.
Fiber ersetzt den Virtual DOM nicht
Oft wird behauptet, Fiber habe „den Virtual DOM ersetzt“. Das ist nicht der Fall. Beide beantworten unterschiedliche Fragen.
Der Virtual DOM ist eine Beschreibung davon, wie die Benutzeroberfläche aussehen sollte. React vergleicht diese Beschreibung mit der vorherigen, um herauszufinden, was geändert werden muss:
Virtual DOM
↓
"What should the UI look like?"
Fiber ist das System, das React verwendet, um die zur Erreichung dieses Ziels notwendigen Aufgaben zu organisieren und auszuführen:
Fiber
↓
"How should React organize and process the work required to get there?"
Sie arbeiten zusammen, wobei die eine Darstellung der Benutzeroberfläche und die andere eine Methode zum Verarbeiten von Aufgaben darstellt. Wenn Sie sich die Vergleichsaspekte genauer ansehen möchten, lesen Sie wie Reacts Virtual DOM-Diffing entscheidet, was aktualisiert werden soll.
Der Fiber-Tree während einer Aktualisierung
React behält seinen Fiber-Tree über die gesamte Lebensdauer der Anwendung bei. Ein etwas detaillierteres Beispiel zeigt, wie ein Unterbaum darin eingebettet ist:
App
│
┌─────────┼─────────┐
↓ ↓ ↓
Header Sidebar Content
│
┌──────┴──────┐
↓ ↓
Chart Table
Wenn Props oder State sich ändern, verwendet React diese Struktur, um die Zweige zu finden, die bearbeitet werden müssen, und alle anderen auszuschließen.
Aussetzen des Renderns
Large Update
↓
Work 1
↓
Work 2
↓
Work 3
↓
Work 4
Mit dem synchronen Reconciler mussten alle vier Schritte nacheinander ausgeführt werden. Mit Fiber kann React einige davon verarbeiten, dann den Kontrollfluss abgeben, damit der Browser auf Eingaben reagieren oder ein Frame zeichnen kann, und anschließend fortfahren:
Work 1
↓
Work 2
↓
Pause
↓
Browser gets an opportunity to handle other work
↓
Resume
↓
Work 3
↓
Work 4
Das ist an sich keine Geschwindigkeitsoptimierung – die Gesamtarbeit bleibt unverändert. Die Arbeit monopolisiert einfach nicht mehr den Thread, was React Raum gibt, sie zu planen.
Zwei Phasen: Änderungen ermitteln und anschließend anwenden
Modernes React betrachtet einen Update nicht als einzigen Schritt von der Darstellung zum DOM:
Render → DOM
Stattdessen durchläuft jeder Update-Vorgang zwei unterschiedliche Phasen:
React Update
│
↓
Render Phase
│
↓
Commit Phase
│
↓
DOM
In der Render-Phase wird die nächste Benutzeroberfläche berechnet
In der Render-Phase beantwortet React die Frage, wie das UI jetzt aussehen sollte. Konkret bedeutet das:
- Es führt Komponentenfunktionen aus und verarbeitet ausstehende Aktualisierungen.
- Es erstellt oder bringt den Fiber-Tree in Einklang.
- Es ermittelt, was sich vom aktuellen Tree unterscheidet.
- Es sammelt die Liste der Änderungen, die angewendet werden müssen.
In diagrammatischer Form fließen der vorherige Tree sowie die neuen Aktualisierungen ein, und es entsteht eine Beschreibung der erforderlichen Arbeiten:
Previous Tree
+
New Updates
↓
Reconciliation
↓
New Work
Weil in dieser Phase nichts den DOM berührt, kann sie in modernen React-Versionen unterbrochen werden. React kann einen großen Teil des nächsten Baums im Hintergrund berechnen, ohne dass jemand einen Zwischenzustand sieht. Das erklärt auch, warum React von einer renderungsfreien Ausführung ohne Nebeneffekte ausgeht: Bei paralleler Renderung kann eine Komponente mehrmals gerendert werden, bevor das Ergebnis festgeschrieben wird. Im Entwicklungsmodus ruft Strict Mode die Render-Logik absichtlich zweimal auf, um Code zu identifizieren, der unter dieser Annahme fehlerhaft funktioniert.
In der Commit-Phase wird das Ergebnis angewendet
Sobald die Änderungen bekannt sind, speichert React sie ab:
Render Phase
↓
Changes determined
↓
Commit Phase
↓
DOM updated
In der Commit-Phase finden die tatsächlichen Änderungen statt: DOM-Node werden eingefügt, aktualisiert oder entfernt, Refs werden angehängt und Layout-Effekte ausgeführt. Eine praktische Methode, die beiden Phasen voneinander zu trennen:
Render Phase
"Let's figure out what needs to change."
Commit Phase
"Now apply those changes."
Warum die Commit-Phase nicht pausiert werden kann
Falls Pausieren so nützlich ist, warum dann nicht überall pausieren? Weil der Bildschirm konstant bleiben muss. Stellen Sie sich vor, React würde mitten im Schreiben in den DOM aufhören:
Update A
↓
DOM partially changed
↓
Pause
↓
Update B
Der Benutzer würde eine Mischung aus alter und neuer Benutzeroberfläche sehen, die nie logischerweise gleichzeitig existiert hätte. Deshalb trennt React die Aufgaben voneinander: Die Bearbeitung von Änderungen kann unterbrochen, neu gestartet oder verworfen werden, doch der Commit führt das fertige Ergebnis auf einmal um. Diese Trennung ist entscheidend, um modernes React zu verstehen.
Scheduling: Nicht alle Updates sind gleich
Durch die Aufteilung der Arbeit in Einheiten kann React herausfinden, welche Arbeiten am wichtigsten sind. Einige Updates sind eindeutig dringender als andere. Als Reaktion darauf:
User clicks a button
ist für den Benutzer in diesem Moment wichtiger als dieses:
Rendering a large list somewhere else
Auf dieselbe Weise auch dieses:
Typing in an input
Es muss sofortig wirken. Eine aufwändige Aktualisierung an einer anderen Stelle der Seite sollte nicht dazu führen, dass die Zeichen hinter dem Keyboard zurückbleiben. Fiber stellt die Struktur bereit, die es React ermöglicht, mit solchen Unterschieden umzugehen und die Arbeiten entsprechend zu ordnen.
Lanes: Wie React Prioritäten kennzeichnet
Intern verwenden moderne React-Tags Aktualisierungen mit Lanes, die deren Priorität kodieren. Anwendungscode befasst sich fast nie direkt mit Lanes; React nutzt sie, um zu entscheiden, welche ausstehenden Aktualisierungen bei einer bestimmten Darstellung verarbeitet werden sollen und welche warten können. Eine vereinfachte Sichtweise:
Updates
│
┌───────────┼───────────┐
↓ ↓ ↓
Urgent Normal Deferred
│ │ │
↓ ↓ ↓
Process Process Process
sooner normally later
Es hilft, drei miteinander verbundene Begriffe voneinander zu trennen, wenn sie gemeinsam auftauchen:
Fiber
↓
Represents work
Scheduler
↓
Helps coordinate when work should happen
Lanes
↓
Represent priority of updates
Fiber beschreibt die Aufgaben, der Scheduler entscheidet, wann sie ausgeführt werden, und die „Lanes“ geben an, wie dringend jede Aktualisierung ist. Die konkrete Umsetzung dieser Komponenten hat sich zwischen den React-Versionen geändert, daher sollte dies als konzeptionelles Modell und nicht als Beschreibung des aktuellen Quellcodes angesehen werden.
Altes gegen Neues, Schritt für Schritt
Vor Fiber war die Abstimmung der Daten synchron und stackbasiert, und sobald sie begann, lief sie einfach weiter:
Update
↓
Reconcile
↓
Continue
↓
Continue
↓
Continue
↓
Finish
Es gab kaum Möglichkeiten, die Arbeit zu unterbrechen oder einer Aktualisierung Vorrang vor einer anderen einzuräumen.
Die Fiber-Architektur integriert Entscheidungen zur Scheduling in den Ablauf:
Update
↓
Create / schedule work
↓
Process Fiber units
↓
Prioritize
↓
Pause / resume / restart when appropriate
↓
Complete render
↓
Commit
Wenn man beide Abläufe nebeneinander stellt, wird der Unterschied deutlich:
BEFORE FIBER:
Component Tree
↓
Synchronous Reconciliation
↓
Finish Everything
↓
Commit
AFTER FIBER:
Component Tree
↓
Fiber Tree
↓
Units of Work
↓
Prioritize / Schedule
↓
Render
↓
Commit
Es ging nicht darum, dass React schneller wurde, sondern darum, dass es die Kontrolle darüber erhielt, wie und wann die Darstellung erfolgt.
Häufige Missverständnisse
Fiber fügt keine Threads hinzu
Fiber teilt React nicht auf mehrere Threads auf:
React
├── Thread 1
├── Thread 2
└── Thread 3
Reacts JavaScript läuft weiterhin im Hauptthread des Browsers. Fiber ist eine Form der kooperativen Scheduling: React gibt freiwillig zwischen Arbeitseinheiten ab, damit andere Aufgaben dran kommen können. Das unterscheidet sich grundlegend von Web Workers, die tatsächlich Code auf einem separaten Thread ausführen.
Konkurrenz bedeutet nicht gleichzeitig
Fiber macht konkurrenzbasiertes Rendering möglich, doch das Wort „konkurrenzbasiert“ kann leicht falsch verstanden werden. Es bedeutet nicht, dass React alles zur gleichen Zeit rendernt. Vielmehr kann React eine Aktualisierung vorbereiten, ohne die Anwendung während des gesamten Zeitraums eines langwierigen Renderings zu blockieren. Eine typische Abfolge:
Low-priority update
↓
React starts rendering
↓
Higher-priority update arrives
↓
React can prioritize the important work
↓
Continue / restart lower-priority work
Eine Renderung mit niedriger Priorität kann beiseitegelegt werden, wenn etwas Dringenderes ansteht, und anschließend fortgesetzt oder von vorne begonnen werden. Das ist der Mechanismus hinter vielen reibungsloseren Interaktionen in modernem React. Wie sich das im Rahmenkontext darstellt, wird im Artikel zu partial pre-rendering and concurrent rendering aus der Sicht von Next.js erläutert.
Fiber arbeitet nicht „eine Komponente nach der anderen“
Auch ist es verlockend, sich Fiber so vorzustellen, dass React zunächst genau eine Komponente rendernt, dann die nächste und so weiter:
Component 1
Component 2
Component 3
Das ist zu einfach. Reacts Durchsuchen, Gruppieren und Planen sind komplexer als bei einer einfachen Liste; was Fiber bietet, ist ein Arbeitsmodell, das viel feiner granuliert ist als der alte rekursive Ansatz.
Übergänge in der Praxis
Übergänge sind die Stellen, an denen die Scheduling-Logik von Fiber im Anwendungscode sichtbar wird. Nehmen wir ein Suchfeld, in das der Benutzer soeben etwas eingegeben hat:
User types: "rea"
Diese Tastenbetätigung löst zwei verschiedene Arten von Aufgaben aus:
1. Update the input immediately
2. Update a huge search result list
Die Aktualisierung des Eingabefeldes ist das, was der Benutzer beobachtet; die Neuberechnung einer langen Ergebnisliste kann aufwändig sein. React ermöglicht es, die zweite Art von Aufgabe als nicht dringend zu kennzeichnen, indem man die Zustandsaktualisierung in startTransition einbettet:
startTransition(() => {
setSearchResults(results);
});
Die eingegebenen Zeichen werden als dringende Aktualisierung behandelt, sodass das Feld weiterhin reaktiv bleibt:
User Input
↓
Urgent Update
↓
Keep UI responsive
Die Ergebnisliste wird als Übergang behandelt, den React mit geringerer Priorität darstellen kann und unterbrechen kann, falls der Benutzer weiter eintippt:
Search Results
↓
Transition
↓
Can be handled with lower priority
Zwei praktische Hinweise. Erstens machen Übergänge die aufwändigen Aufgaben nicht günstiger; sie verhindern lediglich, dass diese dringende Aktualisierungen blockieren, sodass eine langsame Liste dennoch von Memoisierung oder Virtualisierung profitieren kann. Zweitens sollte der eigene Zustand der Eingabe außerhalb des Übergangs bleiben, andernfalls wird das Tippen selbst verschoben und das Feld wirkt träge. All diese Scheduling-Mechanismen wären ohne die unterbrechbare Render-Phase, die Fiber bietet, nicht möglich.
Warum React eine neue Grundlage benötigte
Vor Fiber hatte React bereits den größten Teil dessen, was man mit ihm in Verbindung bringt:
- einen Virtual DOM
- Reconciliation-Verfahren
- ein Komponentenmodell
- effiziente DOM-Aktualisierungen
Die Neugestaltung richtete sich auf die Zukunft und nicht darauf, etwas Defektes zu beheben. Anwendungen entwickelten sich gleichzeitig in mehreren Richtungen weiter:
Larger
+
More interactive
+
More data-driven
+
More complex
Dieses Wachstum bedeutete, dass React sich um mehr kümmern musste als nur darum, was sich geändert hat. Es musste auch Fragen beantworten wie zum Beispiel, wann eine Aufgabe ausgeführt werden sollte, wie wichtig ein Update ist, ob die Arbeit pausiert werden kann, ob ein anderes Update vorrangig bearbeitet werden sollte, und wie man vermeiden kann, die Interaktionen zu blockieren, die den Nutzern am wichtigsten sind. Fiber ist die Architektur, die es ermöglicht, diese Fragen zu beantworten.
Szenario eines Dashboards
Betrachten wir ein Analyse-Dashboard mit mehreren ressourcenintensiven Bereichen:
Dashboard
│
├── Navigation
├── Filters
├── Revenue Chart
├── User Chart
├── Large Data Table
└── Notifications
Wenn der Benutzer einen Filter ändert, könnte eine naive Implementierung die Diagramme und die große Tabelle in einem einzigen Durchlauf neu rendern, wodurch die Reaktion des Filter-Controls langsam erscheint. Unter der Fiber-Architektur fließt dieselbe Interaktion durch priorisierte Aufgaben:
User changes filter
↓
Update begins
↓
React performs reconciliation
↓
Work is represented through Fiber
↓
Updates can be prioritized
↓
Rendering completes
↓
Commit changes
Die Diagramme und Tabellen müssen noch erneut berechnet werden. Was sich verbessert, ist die Reaktionsfähigkeit, da React diese Aufgabe übernimmt.
Fiber im Vergleich zu verwandten Konzepten
Fiber und der Virtuelle DOM
Der Virtuelle DOM ist eine Darstellung der Benutzeroberfläche, die React verwendet, um herauszufinden, was geändert werden muss:
UI State
↓
Virtual Representation
Fiber ist die interne Architektur und Datenstruktur, durch die React die Darstellung bearbeitet:
Component / Element
↓
Fiber
↓
Reconciliation + Scheduling
Zusammen bilden sie Reacts Darstellungssystem:
Virtual DOM
+
Fiber Architecture
↓
React Rendering System
Verwandt, aber nicht austauschbar.
Fiber und Web Workers
Beide beheben völlig unterschiedliche Probleme. Fiber befasst sich mit:
Rendering
Reconciliation
Scheduling
Prioritization
Ein Web Worker hingegen dient dazu:
Running JavaScript
outside the main UI execution context
Ihre Struktur sieht so aus, wobei aufwendige Berechnungen von dem Thread entfernt werden, der die Benutzeroberfläche steuert:
Main Thread
│
├── UI
├── React
│
↓
Web Worker
│
↓
Heavy computation
Fibers führen die Rendering-Arbeit von React niemals in einen Worker um. Wenn Sie rechenintensive Aufgaben haben, die nicht mit dem Rendering zu tun haben – wie z. B. Parsing oder numerische Berechnungen – ist ein Worker dennoch das richtige Werkzeug; der Artikel zu dedizierten, gemeinsamen und Service Workers erläutert diese Optionen ausführlich.
Was das für Ihren Code bedeutet
In der täglichen Arbeit greifen Sie niemals direkt auf Fibers zu. Sie schreiben Komponenten:
function App() {
return <Dashboard />;
}
und lösen Aktualisierungen aus:
setState(newValue);
React wandelt diese Aktionen im Hintergrund in Fiber-Arbeiten um. Ihr Code befindet sich an der Spitze einer Pipeline, deren untere Ebenen Sie in der Regel nicht berücksichtigen müssen:
Your React Code
↓
React APIs
↓
Fiber Architecture
↓
Reconciliation
↓
Scheduling / Prioritization
↓
Commit
↓
DOM
Man erstellt Fiber-Node niemals manuell. Was wichtig ist, ist das mentale Modell: Halten Sie die Render-Logik rein, platzieren Sie Nebeneffekte in Effects oder Handlers und verwenden Sie Transitions für teure, nicht dringende Aktualisierungen.
Die kürzeste mögliche Zusammenfassung
Der alte Reconciler folgte einer einfachen Regel:
"Start rendering → keep going → finish."
Fiber folgt einer anderen:
"Break rendering into work → decide how to schedule it
→ complete the render → commit the result."
Genau dieser Unterschied ist im Grunde der gesamte architektonische Wandel.
Zusammenfassend
Der Stack-Reconciler hat React jahrelang gut gedient. Fiber adressiert Anwendungen, die über seine Möglichkeiten hinausgewachsen sind. Die Entwicklung verläuft von eingeschränkter Steuerung:
Old React
↓
Synchronous Stack Reconciler
↓
Limited control over rendering work
zu einem Modell, in dem die Aufgaben explizit definiert, planbar und priorisiert werden können:
React Fiber
↓
Fiber Tree + Units of Work
↓
More flexible reconciliation
↓
Scheduling + Prioritization
↓
Concurrent Rendering Capabilities
Wenn jemand fragt, was React Fiber ist, beschreibt die Aussage „der neue Rendering-Engine“ es nur unzureichend. Eine präzisere Antwort lautet, dass Fiber Reacts interne Reconciliation-Architektur ist, die das Rendering als Arbeitseinheiten modelliert, damit React diese Arbeiten gezielt planen, priorisieren, unterbrechen und wieder aufnehmen kann.
Kernpunkte
- Fiber wurde in React 16 eingeführt und ersetzte den rekursiven, synchronen Stack Reconciler.
- Eine Fiber ist ein Objekt, das eine Rendering-Arbeitseinheit darstellt und in einem Baum strukturiert ist, den React durchlaufen und pausieren kann.
- In der Render-Phase werden Änderungen berechnet und können unterbrochen werden; in der Commit-Phase werden sie in einem durchgängigen Schritt umgesetzt.
- Lanes sowie der Scheduler nutzen Fibers Struktur, um dringenden Updates Vorrang vor verzögerten zu geben.
Verwandte Artikel
- React’s Scheduler und der Event Loop: Wer entscheidet wirklich, wann Aufgaben ausgeführt werden — Erfahren Sie, wie Reacts kooperativer Scheduler innerhalb des JavaScript-Event Loops läuft, warum Übergänge abgebrochen werden können und warum kein Scheduler einen blockierten Thread retten kann.
- Verstehen von React Lanes: Wie Bitmasks Aktualisierungs-Prioritäten kodieren — Erfahren Sie, wie React mehrere Aktualisierungs-Prioritäten mithilfe von Bitmasks in eine einzige Ganzzahl kodiert und warum bitweise Operationen einfache boolesche Flags bei der Scheduling-Logik ersetzen.