Bisher haben wir React als gegeben hingenommen: setState aufrufen, und "irgendwie" aktualisiert sich die Seite. Ab hier schauen wir UNTER die Haube – was passiert GENAU zwischen einem setState-Aufruf und der sichtbaren Änderung im Browser?

Das Problem, das React lösen wollte

Direkte DOM-Manipulation (document.querySelector(...).innerHTML = ...) ist TEUER: jede Änderung kann Layout-Neuberechnung ("Reflow") und Neuzeichnen ("Repaint") des gesamten betroffenen Bereichs auslösen. Bei häufigen, kleinteiligen UI-Updates (wie bei unserem RenderCounter, der bei jedem Klick aktualisiert) wäre naives "bei jeder State-Änderung das komplette HTML neu erzeugen und einsetzen" katastrophal langsam.

Was ist das Virtual DOM wirklich?

Das Virtual DOM ist KEINE geheime Browser-API – es ist ein simples JavaScript-Objektbaum, den React selbst verwaltet, eine leichtgewichtige BESCHREIBUNG dessen, wie das echte DOM aussehen SOLL. Wenn Sie JSX wie <h1>{{name}}</h1> schreiben, kompiliert Babel das zu React.createElement('h1', null, name) – das Ergebnis ist ein simples Objekt wie {{ type: 'h1', props: {{ children: name }} }}, KEIN echter DOM-Knoten.

// Das JSX, das Sie schreiben:
<h1 className="title">Hallo Welt</h1>

// ...wird zu diesem JavaScript-Aufruf kompiliert:
React.createElement('h1', { className: 'title' }, 'Hallo Welt')

// ...der DIESES simple Objekt zurückgibt (stark vereinfacht):
{
  type: 'h1',
  props: { className: 'title', children: 'Hallo Welt' },
}

Reconciliation: der Vergleichs- und Update-Prozess

Reconciliation ("Abgleich") ist der Prozess, mit dem React herausfindet, was sich zwischen zwei Virtual-DOM-Bäumen geändert hat. Bei jedem setState erzeugt React einen KOMPLETT NEUEN Virtual-DOM-Baum für die betroffene Komponente (und ihre Kinder) und vergleicht ihn mit dem vorherigen ("Diffing"). Nur die TATSÄCHLICH geänderten Teile werden als minimale Anweisungen an das echte DOM weitergegeben – eine gezielte textContent-Änderung statt eines kompletten innerHTML-Neuaufbaus.

Warum React NICHT jeden möglichen Baumvergleich probiert

Ein mathematisch VOLLSTÄNDIGER Baumvergleich zweier beliebiger Bäume ist rechnerisch extrem teuer (O(n³) im allgemeinen Fall). React nutzt stattdessen zwei praktische Heuristiken, die den Vergleich auf O(n) reduzieren:

• Verschiedene Element-Typen erzeugen verschiedene Bäume. Wechselt ein <div> zu einem <span> an derselben Stelle, wirft React den GESAMTEN alten Teilbaum weg und baut komplett neu, statt nach Gemeinsamkeiten zu suchen.
• Keys identifizieren Elemente über Renders hinweg. Genau das key-Prop aus dem .map()-Aufruf in unserer ProductListPage (Kapitel 7 aus "React für Einsteiger") – ohne stabile Keys vergleicht React Listen-Elemente nur nach POSITION, was bei Einfügungen/Löschungen in der Mitte einer Liste zu unnötigen Neu-Erstellungen führt.

Das Key-Problem am eigenen Projekt sichtbar machen

Erinnern Sie sich an ProductCards isFavorite-State aus "React für Einsteiger"? Er lebt INNERHALB der Komponenteninstanz, verknüpft über den key. Öffnen Sie den React DevTools "Components"-Tab, wählen Sie eine ProductCard, setzen Sie isFavorite manuell auf true (im DevTools-Panel editierbar). Wechseln Sie dann auf die nächste Pagination-Seite und wieder zurück – React erstellt bei gleichbleibenden key-Werten (product.sku) für WIEDERKEHRENDE Produkte KEINE neue Komponenteninstanz, ihr lokaler State bliebe (bei gleichem Produkt) erhalten. Ohne stabile, eindeutige Keys (z. B. bei Verwendung des Array-INDEX als Key bei einer sich ändernden Liste) würde React hier fälschlich State zwischen POSITIONEN statt zwischen ECHTEN Entitäten verknüpfen.

Die Verbindung zu den letzten Kapiteln

Jetzt schließt sich der Kreis zu allem, was wir in den letzten Kapiteln gelernt haben: React.memo (Kapitel 31) überspringt Reconciliation für eine Komponente KOMPLETT, wenn Props unverändert sind – die teure Diff-Berechnung entfällt dann ganz. Virtualisierung (Kapitel 32) reduziert, wie viele Elemente überhaupt in den zu vergleichenden Bäumen existieren. Stabile Keys sorgen dafür, dass Reconciliation bei Listen-Änderungen MINIMALE statt MAXIMALE Arbeit verursacht.