Interviewfragen zum State Management mit Antworten

Beispielfragen

Ein paar Fragen aus jedem Level mit richtiger Antwort und Erklärung.

State Management · Junior

1. Was ist „State“ in einer React-Komponente?
   ▸Antwort zeigen

   Richtige Antwort: Daten, deren Änderung ein erneutes Rendern auslöst

   State ist das Gedächtnis der Komponente zwischen Renderings: ein Zählerwert, eine Formulareingabe, ob ein Menü offen ist. Eine normale let-Variable wird bei jedem Rendern zurückgesetzt, und ihre Änderung sagt React nicht, dass die UI aktualisiert werden soll. Props sind schreibgeschützte Eingaben, die dem Elternteil gehören.

2. Wann sollte man das funktionale Update setCount(c => c + 1) statt setCount(count + 1) verwenden?
   ▸Antwort zeigen

   Richtige Antwort: Wenn der neue Wert vom vorherigen abhängt

   count ist ein Schnappschuss des aktuellen Renderings. Drei Aufrufe setCount(count + 1) in einem Handler ergeben +1, drei Aufrufe setCount(c => c + 1) ergeben +3, weil jeder Updater das Ergebnis des vorigen bekommt. Es schützt auch vor veralteten Closures in Timern und Effects.

3. Wie entfernt man ein Element mit id aus einem Array im State?
   ▸Antwort zeigen

   Richtige Antwort: setItems(items.filter(i => i.id !== id))

   State muss unveränderlich aktualisiert werden: filter, map, Spread und toSorted erzeugen ein neues Array. splice und delete verändern das bestehende, die Referenz bleibt gleich, und React überspringt das Update.

4. Warum übergibt man eine Funktion an useState(() => createInitialTodos())?
   ▸Antwort zeigen

   Richtige Antwort: Damit die teure Berechnung nur beim ersten Rendern läuft

   useState(createInitialTodos()) ruft die Funktion bei jedem Rendern auf, obwohl das Ergebnis nur einmal genutzt wird. Ein lazy Initializer useState(createInitialTodos) wird nur beim Mounten aufgerufen. Er muss synchron und rein sein.

State Management · Middle

1. Wie setzt man den State einer Formular-Komponente zurück, wenn sich der ausgewählte Nutzer ändert?
   ▸Antwort zeigen

   Richtige Antwort: Mit key={userId} rendern, damit React die Komponente neu erzeugt

   Ein anderer key lässt React sie als neue Komponente behandeln: der alte State fällt weg, die Anfangswerte gelten. Ein zurücksetzender Effect rendert erst veraltete Daten und korrigiert sie dann - ein zusätzliches Rendern und ein sichtbares Flackern.

2. Wie gibt man dispatch aus useReducer tief in den Baum weiter, ohne Prop Drilling?
   ▸Antwort zeigen

   Richtige Antwort: dispatch in einen eigenen Context legen

   Das Muster „Reducer + Context“: ein Context für state, ein anderer für dispatch. Komponenten, die nur Actions senden (Buttons, Formulare), lesen den stabilen Dispatch-Context und rendern nicht neu, wenn sich der State ändert.

3. Wozu dient das dritte Argument init in useReducer(reducer, arg, init)?
   ▸Antwort zeigen

   Richtige Antwort: Lazy Initialisierung beim ersten Rendern

   useReducer(reducer, username, createInitialState) vermeidet, einen teuren Anfangszustand bei jedem Rendern neu zu berechnen - wie ein lazy Initializer bei useState. init lässt sich auch zum Zurücksetzen wiederverwenden.

4. Eine Komponente nutzt nur theme aus einem großen AppContext, rendert aber bei jedem Warenkorb-Update neu. Was hilft?
   ▸Antwort zeigen

   Richtige Antwort: Den Context nach Domäne und Änderungshäufigkeit in kleinere aufteilen

   React.memo verhindert kein Neurendern durch einen Context, den die Komponente liest. Getrennte ThemeContext und CartContext beschränken Updates auf die Konsumenten, die sie brauchen. Für sehr häufige Updates nimm einen Store mit Selektoren.

State Management · Senior

1. Warum abonnieren Redux, Zustand und ähnliche Bibliotheken über useSyncExternalStore?
   ▸Antwort zeigen

   Richtige Antwort: Es garantiert beim nebenläufigen Rendern einen konsistenten Schnappschuss (kein Tearing)

   Beim nebenläufigen Rendern kann React ein Rendern pausieren; ändert sich in der Zeit ein externer Store, könnten einige Komponenten alte und andere neue Werte lesen. useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot) verhindert das und unterstützt SSR.

2. Was ist der Unterschied zwischen dem Modell „Selektor abonnieren“ (Redux, Zustand) und Context?
   ▸Antwort zeigen

   Richtige Antwort: Ein Store benachrichtigt Komponenten, und jede rendert nur neu, wenn sich ihr Teil änderte

   Context hat keine Selektoren: jede Änderung von value rendert jeden Konsumenten neu. Stores führen den Selektor jedes Abonnenten aus und vergleichen die Ergebnisse, die Updates sind also feingranular. Bibliotheken wie use-context-selector emulieren das auf Basis von Context.

3. Wo sollte der Zustand eines Listenfilters (Suchtext, Sortierung, Seite) in einer App mit Routing idealerweise liegen?
   ▸Antwort zeigen

   Richtige Antwort: In den Suchparametern der URL

   Die URL ist auch State. Filter in ?q=&sort=&page= machen Links teilbar und den Verlauf sinnvoll, und Loader/Query-Keys können daraus abgeleitet werden. Debounce das Tippen und ersetze (statt hinzuzufügen) History-Einträge pro Tastendruck.

4. Welche Einteilung von State hilft in einer großen App bei der Werkzeugwahl?
   ▸Antwort zeigen

   Richtige Antwort: Server-Cache, URL, Formular, lokaler und globaler Client-State

   Jede Art hat ihren natürlichen Ort: Server-Cache - TanStack Query/RTK Query/SWR/Loader; URL - der Router; Formulare - lokaler State oder eine Formularbibliothek; UI - useState; wirklich globaler Client-State - Context oder ein Store. Alles in einen Store zu legen macht ihn zum Flaschenhals.

Kombinierte Tests mit diesem Thema

Fragen aus mehreren Themen auf einmal, wie im Vorstellungsgespräch für eine konkrete Stelle.