Senior React Frontend — React-Interviewfragen

Was ändert sich wirklich, wenn eine Komponente zur Server Component wird?

Sie läuft ausschließlich auf dem Server, schickt also nie JavaScript an den Browser und kann direkt mit einer Datenbank sprechen, kann aber keinen State halten, keine Effects nutzen und keine Handler anhängen. Die eigentliche Design-Arbeit besteht darin, die Grenze zu ziehen: Interaktive Blätter bleiben Client Components, alles darüber kann Server sein. Markiert man eine Komponente mit „use client", wird alles, was sie importiert, ebenfalls Client-Code — und genau so hört ein Bundle unbemerkt auf, kleiner zu werden.

Deine App schneidet bei INP schlecht ab. Wie gehst du vor?

INP misst die Verzögerung zwischen einer Interaktion und der visuellen Reaktion, also suchst du nach langen Tasks auf dem Main Thread während der Interaktion. Übliche Ursachen sind ein State-Update, das einen großen Baum neu rendert, ein teurer synchroner Handler und noch laufende Hydration. Werkzeuge sind der Profiler und Long-Task-Einträge; Lösungen sind, das Re-Rendering zu verkleinern, useTransition für nicht dringende Updates und insgesamt weniger JavaScript auszuliefern.

Wie entscheidest du, was in eine Design-System-Komponente gehört und was in die Feature?

Eine Design-System-Komponente besitzt das Aussehen und die Interaktion, die überall gleich sein müssen, und nichts, was eine bestimmte Feature betrifft. Sobald sie einen Prop bekommt, der nach einem Screen benannt ist, wurde die Grenze überschritten. Der Test ist, ob ein zweites Team sie nutzen könnte, ohne den Code des ersten Teams zu lesen, und ob eine Änderung ein koordiniertes Release erfordert oder eine lokale Anpassung reicht.

Ein Hydration-Mismatch tritt nur in Produktion auf. Wie gehst du beim Debuggen vor?

Das bedeutet, dass das Server-HTML und der erste Client-Render nicht übereinstimmen, und die Ursachen sind eine kurze Liste: Date.now oder Math.random während des Renders, das Lesen von localStorage oder window im Render-Pfad, Locale- oder Zeitzonen-Formatierung und Browser-Extensions, die das DOM umschreiben. Reproduziere das Produktions-Rendering lokal und grenze das Problem ein, indem du Teile des Baums per Suspense ausklammerst. Die Warnung einfach zu unterdrücken ist die falsche Lösung — die beiden Bäume bleiben dann tatsächlich unterschiedlich.

Wann ist ein Monorepo im Frontend die richtige Antwort, und wann ist es nur Overhead?

Richtig ist es, wenn mehrere Apps Komponenten teilen und du eine Änderung gebündelt reviewen und über alle hinweg releasen willst, mit Tooling wie Turborepo oder Nx, das die Builds inkrementell hält. Overhead ist es für eine einzelne App mit ein paar Libraries, wo du für Cache-Konfiguration und CI-Komplexität zahlst, die du gar nicht brauchst. Die entscheidende Frage ist, ob paketübergreifende Änderungen wöchentlich vorkommen oder zweimal im Jahr.

Wie würdest du eine große Codebase mit Class Components auf Hooks migrieren?

Nicht als eigenständiges Projekt mit eigenem Deadline. Konvertiere bei Berührung: Jede Komponente, die ohnehin für eine Feature geändert wird, wird gleich mit umgeschrieben, sodass die Migration bei Arbeit mitläuft, die sowieso stattfindet. Fange bei den Blättern an, nicht bei den Containern, weil dort am wenigsten umgebende Logik hängt. Lass beide Stile beliebig lange nebeneinander bestehen und akzeptiere, dass manche Komponenten nie konvertiert werden — das Ziel ist eine Codebase, die sich leichter ändern lässt, keine abgehakte Checkliste.