Im letzten Kapitel haben wir gelernt, DASS React einen neuen Virtual-DOM-Baum erzeugt und mit dem alten vergleicht. Aber WIE macht React das eigentlich, Schritt für Schritt, ohne dabei den Browser einfrieren zu lassen? Die Antwort heißt Fiber – Reacts internes Rendering-Modell seit React 16 (davor: die einfachere, aber unterbrechbarkeitslose "Stack Reconciler"-Architektur).

Das Problem, das Fiber löste

Vor React 16 war das Rendern ein einziger, UNUNTERBROCHENER rekursiver Funktionsaufruf-Stapel – sobald React mit dem Berechnen eines Updates begann, musste es bis zum Ende durchlaufen, BEVOR der Browser irgendetwas anderes tun konnte (auch keine Tastatureingabe verarbeiten, keine Animation zeichnen). Bei einem großen Komponentenbaum konnte das den "Main Thread" für spürbare Millisekunden blockieren – genau das "Freeze"-Gefühl, das wir in Kapitel 33 mit der künstlich verlangsamten Suche selbst erzeugt haben.

Was ist ein "Fiber" konkret?

Ein Fiber ist ein JavaScript-Objekt, das EINE Arbeitseinheit repräsentiert – ungefähr (aber nicht exakt) eine Komponenteninstanz im Baum. Anders als der alte rekursive Ansatz ist ein Fiber-Baum eine EXPLIZITE Datenstruktur mit Verweisen auf child (erstes Kind), sibling (nächstes Geschwister) und return (Elternteil) – React kann diesen Baum daher wie eine Liste Schritt für Schritt DURCHLAUFEN, statt ihn rekursiv abzuarbeiten, und dabei jederzeit PAUSIEREN und später WEITERMACHEN.

Die zwei Phasen: Render und Commit

Reacts Arbeit gliedert sich in zwei fundamental unterschiedliche Phasen:

• Render-Phase (unterbrechbar): React geht den Fiber-Baum durch, ruft Komponentenfunktionen auf, berechnet, was sich geändert hat. Diese Phase kann pausiert, fortgesetzt oder sogar VERWORFEN werden (z. B. wenn eine dringendere Aktualisierung dazwischenkommt – genau das Prinzip hinter useTransition aus Kapitel 33).
• Commit-Phase (NICHT unterbrechbar): Sobald die Render-Phase fertig ist, wendet React die berechneten Änderungen SYNCHRON und AM STÜCK auf das echte DOM an. Diese Phase muss ununterbrochen laufen, damit der Nutzer nie einen "halb aktualisierten" Bildschirm sieht.

Prioritäten: nicht alle Updates sind gleich wichtig

Fiber ermöglicht es React, Updates nach PRIORITÄT zu ordnen (intern über ein System namens "Lanes"). Eine Tastatureingabe hat eine höhere Priorität als eine startTransition-eingepackte Aktualisierung (Kapitel 33) – React kann daher die dringende Eingabe ZUERST verarbeiten, selbst wenn die Berechnung der weniger dringenden Aktualisierung bereits begonnen hatte. Genau DIESE Fähigkeit – Arbeit nach Dringlichkeit zu ordnen und zu unterbrechen – ist es, was useTransition/useDeferredValue aus Kapitel 33 dem Entwicklerteam zugänglich macht. Ohne Fiber gäbe es diese Hooks schlicht nicht.

StrictMode neu verstanden

Erinnern Sie sich an <StrictMode> aus main.jsx ("React für Einsteiger" Kapitel 2), das manche Funktionen im Entwicklungsmodus doppelt aufruft? Jetzt ergibt das mehr Sinn: React testet damit ABSICHTLICH, ob Ihre Komponenten robust gegenüber einer UNTERBROCHENEN und dann WIEDERHOLTEN Render-Phase sind – genau das Szenario, das Fiber in echten Apps unter Last erzeugen kann. Eine Komponentenfunktion, die bei zweimaligem Aufruf unterschiedliche Ergebnisse liefert (z. B. wegen eines Seiteneffekts DIREKT im Funktionskörper statt in useEffect), ist ein Bug, den StrictMode aufdecken soll.

Warum das für Ihre tägliche Arbeit relevant ist

• Es erklärt, warum Komponentenfunktionen "rein" sein MÜSSEN (keine Seiteneffekte im Funktionskörper) – eine unterbrochene, verworfene, oder mehrfach ausgeführte Render-Phase darf niemals sichtbare Nebenwirkungen haben.
• Es erklärt, warum useEffect existiert, statt Seiteneffekte einfach im Funktionskörper zu schreiben – Effekte laufen GARANTIERT genau einmal pro tatsächlichem Commit, nicht pro (möglicherweise verworfenem) Render-Versuch.
• Es ist häufiges Interview-Wissen (siehe Kapitel 47, Interview-Vorbereitung) – "Was ist React Fiber?" ist eine der klassischsten Fragen für Fortgeschrittenen-Interviews.