Das letzte Kapitel dieser Serie: eine Sammlung typischer React-Interview-Fragen für Fortgeschrittenen-Positionen – JEDE Antwort verweist zurück auf das Kapitel, in dem wir das Thema an UNSEREM eigenen Projekt praktisch erarbeitet haben, statt abstrakter Auswendig-Lern-Antworten.

"Was ist das Virtual DOM, und warum nutzt React es?"

Eine gute Antwort erwähnt: das Virtual DOM ist eine leichtgewichtige JavaScript-Objektrepräsentation des UI-Baums, React vergleicht ZWEI Virtual-DOM-Bäume ("Diffing"/"Reconciliation") um MINIMALE echte DOM-Operationen abzuleiten, statt das komplette DOM bei jeder Änderung neu aufzubauen. Vertiefung: Kapitel 34.

"Was ist React Fiber?"

Reacts internes Rendering-Modell seit Version 16 – ermöglicht UNTERBRECHBARES Rendern (Render-Phase) getrennt von der synchronen DOM-Aktualisierung (Commit-Phase), Grundlage für Priorisierung/Concurrent Features. Eine STARKE Antwort verbindet das direkt mit useTransition als PRAKTISCHES Beispiel. Vertiefung: Kapitel 35, praktisch erlebt in Kapitel 33.

"Warum sind Keys in Listen wichtig, und warum nicht den Array-Index nutzen?"

Keys geben React eine STABILE Identität für Elemente über mehrere Renders hinweg, damit lokaler State und DOM-Knoten korrekt der RICHTIGEN Entität zugeordnet bleiben (nicht der Position). Der Array-Index als Key bricht das bei Einfügen/Löschen/Umsortieren in der Mitte einer Liste – Positionen verschieben sich, State "springt" zwischen falschen Elementen. Vertiefung: Kapitel 34, mit product.sku in unserer ProductListPage als durchgängiges Praxisbeispiel.

"Wann Context API, wann eine State-Management-Bibliothek?"

Context: seltene Änderungen, Verbraucher können mit "alle rendern bei jeder Änderung" leben (Theme, Sprache). Zustand/Redux: häufige Änderungen, gezielte Abonnements über Selektoren nötig, um unnötige Re-Renders zu vermeiden. Eine ÜBERZEUGENDE Antwort demonstriert das Re-Render-Problem konkret, wie wir es mit RenderCounter selbst bewiesen haben. Vertiefung: Kapitel 27-29.

"Erkläre den Unterschied zwischen React.memo, useMemo und useCallback"

• React.memo: verhindert den Re-Render einer KOMPONENTE, wenn Props unverändert sind.
• useMemo: cached einen berechneten WERT zwischen Renders, solange Abhängigkeiten gleich bleiben.
• useCallback: cached eine FUNKTIONSREFERENZ zwischen Renders – im Grunde useMemo speziell für Funktionen.

Die BESTE Antwort erklärt auch, WARUM sie oft ZUSAMMEN gebraucht werden – memo allein bringt nichts, wenn eine Inline-Funktion als Prop übergeben wird (unsere eigene Falle aus Kapitel 31 mit onAddToCart). Vertiefung: Kapitel 31.

"Wann läuft useEffect relativ zum Rendern?"

NACH dem Commit, nicht während der (unterbrechbaren) Render-Phase – deshalb dürfen Seiteneffekte (API-Aufrufe, DOM-Messungen, Event-Listener) nicht direkt im Komponentenkörper stehen, sondern gehören in useEffect. Vertiefung: Kapitel 35 erklärt das WARUM (Fiber-Phasen), "React für Einsteiger" Kapitel 8 das WIE.

"Was fangen Error Boundaries NICHT ab?"

Event-Handler-Fehler, asynchrone Fehler (setTimeout, Promises), Server-Side-Rendering-Fehler, Fehler in der Error Boundary SELBST. Eine gute Antwort nennt auch, WARUM sie als Klassenkomponente geschrieben werden müssen (kein Hook-Äquivalent für getDerivedStateFromError/componentDidCatch). Vertiefung: Kapitel 39.

"Was ist ein Higher-Order Component, und warum bevorzugt man heute Hooks?"

Eine Funktion, die eine Komponente nimmt und eine erweiterte Komponente zurückgibt. Nachteile: "Wrapper Hell" bei mehreren kombinierten HOCs, Prop-Namenskollisionen, unklare Props-Herkunft. Custom Hooks lösen dieselben Anwendungsfälle ohne diese Nachteile. Vertiefung: Kapitel 36.

"Warum ist response.json() in TypeScript vom Typ any, und ist das ein Problem?"

TypeScript kann zur Kompilierzeit unmöglich wissen, was ein entfernter Server tatsächlich sendet – der Rückgabetyp einer API-Funktion ist eine Behauptung des Entwicklers, keine automatisch verifizierte Garantie. Für ECHTE Laufzeit-Sicherheit bräuchte man zusätzliche Schema-Validierung (z. B. mit zod). Eine Antwort, die diese Grenze KENNT, wirkt erfahrener als eine, die TypeScript für allmächtig hält. Vertiefung: Kapitel 43.

Bonus: eine typische Live-Coding-Aufgabe selbst nachbauen

Eine häufige Interview-Aufgabe: "Bauen Sie eine Komponente, die Daten von einer API lädt, einen Ladezustand zeigt, Fehler behandelt, und die Liste durchsuchbar macht." Genau das haben Sie bereits mehrfach gebaut – ProductListPage (Kapitel 23/24 aus "React für Einsteiger") ist praktisch eine vollständige Musterlösung. Üben Sie, diese Komponente OHNE Nachschlagen aus dem Gedächtnis nachzuschreiben (Struktur, nicht Wort für Wort) – das ist die realistischste Vorbereitung auf ein Live-Coding-Interview.

Damit ist "React für Profis" abgeschlossen – vom Grenzen-Verständnis der Context API über Performance-Werkzeuge, Reacts interne Architektur, TypeScript-Integration bis zu Testing und Interview-Reife, alles direkt am selben, durchgängigen produktkatalog-web-Projekt erarbeitet, das mit "React für Einsteiger" begann. Herzlichen Glückwunsch!