Middle React Frontend — React-Interviewfragen

Wann hilft useMemo wirklich, und wann ist es nur Rauschen?

Es hilft, wenn die Berechnung tatsächlich teuer ist oder wenn der Wert Abhängigkeit eines anderen Hooks oder einer memoisierten Kindkomponente ist, wo eine neue Referenz bei jedem Render die Memoisierung zunichtemacht. Bei billigen Operationen ist es Rauschen, weil Vergleich und das Vorhalten des Werts ebenfalls etwas kosten. Jeden Wert in useMemo zu packen macht den Code nur schwerer lesbar, ohne messbaren Gewinn.

Eine Komponente rendert viel häufiger als erwartet neu. Wie findest du die Ursache?

Öffne den Profiler, zeichne eine Interaktion auf und nutze „why did this render", um zu sehen, ob es an Props, State oder dem Parent lag. Übliche Ursachen sind ein im Parent inline erzeugtes Objekt oder eine Arrow Function, ein Context, dessen Wert bei jedem Render neu erzeugt wird, oder State, der höher im Baum liegt als nötig. Behebe die Ursache, statt zu React.memo zu greifen, das das Problem nur verdeckt.

Welches Problem löst Context, und wo wird es zum falschen Werkzeug?

Context erspart es, einen Wert durch Komponenten zu reichen, die ihn gar nicht interessiert — Theme, Sprache, aktueller User. Falsch wird es bei häufig wechselndem State, weil bei jeder Änderung alle Consumer neu rendern und es keinen Selector gibt, um nur einen Teil zu abonnieren. Ab diesem Punkt braucht man eine State-Library mit Subscriptions statt eines Context, in dem alles liegt.

Warum braucht man eine Data-Library wie TanStack Query statt useEffect und fetch?

Weil der naiven Version alles fehlt, was Server-Daten schwierig macht: Caching, das Deduplizieren identischer Requests, Refetch bei Fokus-Rückkehr auf das Fenster, Retries und der Schutz davor, in eine bereits unmountete Komponente zu schreiben. Genau das für jeden Screen neu zu bauen ist, wo die Bugs entstehen. Der gedankliche Wechsel besteht darin, dass Server-Daten ein Cache sind, den man synchronisiert, kein State, den man besitzt.

Was ist der Unterschied zwischen useEffect und useLayoutEffect?

useEffect läuft, nachdem der Browser gemalt hat, sodass der User den State kurz vorher sehen kann. useLayoutEffect läuft synchron nach den DOM-Mutationen, aber vor dem Paint, was dieses Flackern verhindert — auf Kosten des Blockierens. Nutze useLayoutEffect nur, wenn du das DOM misst und sofort auf Basis der Messung etwas änderst — eine Tooltip-Position, eine Scroll-Korrektur.

Wie behandelst du einen Fehler, der während des Renders geworfen wird?

Eine Error Boundary fängt ihn ab und zeigt einen Fallback statt einer leeren Seite, denn ein nicht abgefangener Render-Fehler unmountet den kompletten Baum. Boundaries fangen keine Fehler in Event-Handlern oder asynchronem Code ab — das übersieht man leicht, dafür braucht es ganz normales try/catch. Setze Boundaries um sinnvolle Abschnitte, damit ein kaputtes Widget nicht den ganzen Screen mitreißt.

Wo würdest du in einer React-App Code Splitting einsetzen?

Zuerst auf Routen-Ebene, denn wer auf einem Screen landet, sollte nicht den Rest der App mitladen müssen. Danach um wirklich schwere, selten genutzte Komponenten herum — eine Chart-Library, ein Rich-Text-Editor, ein Modal, das die meisten User nie öffnen. Feiner als das zu splitten bringt vor allem zusätzliche Requests und Ladezustände für ein paar Kilobyte ein.