Zustand Interview-Fragen 2026: React State Management und Best Practices

Zustand hat sich als bevorzugte State-Management-Bibliothek für React-Anwendungen etabliert, die mehr als die Context API benötigen, aber weniger Konfigurationsaufwand als Redux erfordern. Mit seiner minimalen API-Oberfläche und dem TypeScript-first Design erscheinen Zustand-Fragen mittlerweile regelmäßig in Frontend-Interviews, insbesondere für Mid-Level- und Senior-React-Positionen.

Grundlegende Zustand-Konzepte für jeden Kandidaten

Zustand v5, veröffentlicht Ende 2024, führte mehrere Breaking Changes gegenüber v4 ein. Die create-Funktion erfordert keinen separaten useStore-Aufruf mehr, und die persist-Middleware verwendet standardmäßig ein synchrones Hydration-Modell. Interviewer erwarten, dass Kandidaten die aktuelle API kennen.

Was unterscheidet Zustand von useState und useReducer?

Zustand-Stores existieren außerhalb des React-Komponentenbaums. Dieser architektonische Unterschied hat drei praktische Konsequenzen:

1. Der State bleibt über Komponenten-Mounts und -Unmounts hinweg bestehen ohne Context-Provider
2. Updates lösen keine Parent-Re-Renders aus, nur abonnierte Komponenten rendern neu
3. Auf den State kann synchron außerhalb von React zugegriffen werden, nützlich für Event-Handler und asynchrone Logik

import { create } from 'zustand'

interface CartStore {
  items: CartItem[]
  addItem: (item: CartItem) => void
  clearCart: () => void
  totalPrice: () => number
}

export const useCartStore = create<CartStore>((set, get) => ({
  items: [],
  addItem: (item) => set((state) => ({ 
    items: [...state.items, item] 
  })),
  clearCart: () => set({ items: [] }),
  totalPrice: () => get().items.reduce((sum, item) => sum + item.price, 0)
}))

Die get-Funktion bietet synchronen Zugriff auf den aktuellen State und vermeidet so das Stale-Closure-Problem, das bei useState häufig auftritt.

Wie handhabt Zustand Re-Renders?

Zustand verwendet standardmäßig Shallow-Equality. Wenn eine Komponente einen Store mit useCartStore() abonniert, erhält sie das gesamte State-Objekt und rendert bei jeder Änderung neu. Die Auswahl spezifischer Slices verhindert unnötige Renders:

// Schlecht: rendert bei jeder Store-Änderung neu
const { items } = useCartStore()

// Gut: rendert nur neu, wenn sich items ändern
const items = useCartStore((state) => state.items)

// Mehrere Werte: shallow comparison verwenden
import { shallow } from 'zustand/shallow'

const { items, totalPrice } = useCartStore(
  (state) => ({ items: state.items, totalPrice: state.totalPrice() }),
  shallow
)

Der Shallow-Comparator aus zustand/shallow führt Referenz-Gleichheit auf Objekt-Eigenschaften durch statt auf dem Objekt selbst.

Zustand vs Context API: Wann welche wählen

Diese Vergleichsfrage erscheint in nahezu jedem Interview, das State Management behandelt. Die Antwort hängt von der Update-Frequenz und der State-Komplexität ab.

Die Context API funktioniert gut für selten ändernde Werte wie Theme oder Locale. Zustand glänzt, wenn State-Updates häufig vorkommen, wie bei Formular-Eingaben, Echtzeit-Daten oder Warenkörben. Die React-Dokumentation zu State Management empfiehlt State nach oben zu heben und Context für "Prop Drilling"-Probleme zu verwenden, während externe Stores für komplexe Update-Muster geeignet sind.

Middleware-Muster in Zustand

Middleware-Fragen testen, ob ein Kandidat Komposition über Konfiguration versteht. Zustand-Middleware umhüllt die Store-Creator-Funktion und fügt Verhalten hinzu, ohne die Kern-API zu modifizieren.

Wie funktioniert die persist-Middleware?

import { create } from 'zustand'
import { persist, createJSONStorage } from 'zustand/middleware'

interface UserPreferences {
  theme: 'light' | 'dark'
  language: string
  setTheme: (theme: 'light' | 'dark') => void
}

export const usePreferencesStore = create<UserPreferences>()(
  persist(
    (set) => ({
      theme: 'light',
      language: 'en',
      setTheme: (theme) => set({ theme })
    }),
    {
      name: 'user-preferences',
      storage: createJSONStorage(() => localStorage),
      partialize: (state) => ({ theme: state.theme, language: state.language })
    }
  )
)

Die partialize-Option schließt Funktionen und abgeleiteten State von der Persistierung aus. Ohne sie schlägt die Serialisierung fehl oder der Storage bläht sich mit unnötigen Daten auf. Die Zustand-Dokumentation zu persist behandelt Migrationsstrategien für Schema-Änderungen.

Mehrere Middleware kombinieren

Middleware wird von innen nach außen komponiert. Die innerste Middleware wird zuerst ausgeführt:

import { create } from 'zustand'
import { devtools, persist, subscribeWithSelector } from 'zustand/middleware'
import { immer } from 'zustand/middleware/immer'

export const useStore = create<StoreState>()(
  devtools(
    persist(
      subscribeWithSelector(
        immer((set) => ({
          // state und actions
        }))
      ),
      { name: 'app-storage' }
    ),
    { name: 'AppStore' }
  )
)

Die immer-Middleware ermöglicht Updates im mutable-Stil, die immutablen State erzeugen. Die subscribeWithSelector-Middleware erlaubt das Abonnieren von State-Slices außerhalb von React-Komponenten.

TypeScript-Integrationsmuster

Zustand v5 hat die TypeScript-Inferenz erheblich verbessert. Das Double-Function-Call-Muster create<Type>()() bietet vollständige Typ-Inferenz für Middleware-Ketten.

Actions typisieren, die auf anderen State referenzieren

interface TodoStore {
  todos: Todo[]
  filter: 'all' | 'active' | 'completed'
  addTodo: (text: string) => void
  toggleTodo: (id: string) => void
  filteredTodos: () => Todo[]
}

export const useTodoStore = create<TodoStore>()((set, get) => ({
  todos: [],
  filter: 'all',
  
  addTodo: (text) => set((state) => ({
    todos: [...state.todos, { id: crypto.randomUUID(), text, completed: false }]
  })),
  
  toggleTodo: (id) => set((state) => ({
    todos: state.todos.map((todo) =>
      todo.id === id ? { ...todo, completed: !todo.completed } : todo
    )
  })),
  
  filteredTodos: () => {
    const { todos, filter } = get()
    switch (filter) {
      case 'active': return todos.filter((t) => !t.completed)
      case 'completed': return todos.filter((t) => t.completed)
      default: return todos
    }
  }
}))

Abgeleiteter State als Funktionen statt Getter vermeidet veraltete Werte. Jeder Aufruf von filteredTodos() liest den aktuellen State.

Stores für große Anwendungen aufteilen

Eine häufige Interview-Frage fragt, wie Zustand für Skalierung strukturiert werden soll. Das Slice-Muster teilt einen Store in Domain-Module auf:

import { StateCreator } from 'zustand'

export interface AuthSlice {
  user: User | null
  isAuthenticated: boolean
  login: (credentials: Credentials) => Promise<void>
  logout: () => void
}

export const createAuthSlice: StateCreator<
  AuthSlice & CartSlice,  // Kombinierter Store-Typ
  [],
  [],
  AuthSlice
> = (set) => ({
  user: null,
  isAuthenticated: false,
  login: async (credentials) => {
    const user = await authApi.login(credentials)
    set({ user, isAuthenticated: true })
  },
  logout: () => set({ user: null, isAuthenticated: false })
})

import { create } from 'zustand'
import { createAuthSlice, AuthSlice } from './slices/authSlice'
import { createCartSlice, CartSlice } from './slices/cartSlice'

export const useStore = create<AuthSlice & CartSlice>()((...args) => ({
  ...createAuthSlice(...args),
  ...createCartSlice(...args)
}))

Slices können über den kombinierten Store-Typ, der an StateCreator übergeben wird, aufeinander referenzieren.

Häufige Interview-Fragen mit Musterantworten

Wann wäre Zustand keine gute Wahl?

Zustand fügt in diesen Szenarien Komplexität ohne Nutzen hinzu:

• Statische Konfigurationsdaten, die sich zur Laufzeit nie ändern
• Formular-State, der von React Hook Form oder ähnlichen Bibliotheken verwaltet wird
• Server-State, der besser von TanStack Query oder SWR gehandhabt wird
• Einfache Parent-Child-Prop-Übergabe mit 2-3 Verschachtelungsebenen

Der Vergleichsabschnitt im Zustand GitHub Repository bietet die Perspektive der Maintainer auf Alternativen.

Wie werden Komponenten getestet, die Zustand verwenden?

Testen erfordert das Zurücksetzen des Store-States zwischen Tests und optional das vollständige Mocken des Stores:

import { act, renderHook } from '@testing-library/react'
import { useCartStore } from './store'

beforeEach(() => {
  // Store auf Initialzustand zurücksetzen
  useCartStore.setState({ items: [], totalItems: 0 })
})

test('addItem erhöht Warenkorb-Anzahl', () => {
  const { result } = renderHook(() => useCartStore())
  
  act(() => {
    result.current.addItem({ id: '1', name: 'Product', price: 10 })
  })
  
  expect(result.current.items).toHaveLength(1)
})

Für Komponententests, die nicht mit echten Stores interagieren sollen, auf Modul-Ebene mocken:

import { vi } from 'vitest'

vi.mock('./store', () => ({
  useCartStore: vi.fn(() => ({
    items: [{ id: '1', name: 'Mock Product', price: 25 }],
    addItem: vi.fn()
  }))
}))

Wie handhabt Zustand asynchrone Operationen?

Im Gegensatz zu Redux hat Zustand keine Middleware-Anforderung für Async. Actions können direkt async-Funktionen sein:

interface ProductStore {
  products: Product[]
  isLoading: boolean
  error: string | null
  fetchProducts: () => Promise<void>
}

export const useProductStore = create<ProductStore>((set) => ({
  products: [],
  isLoading: false,
  error: null,
  
  fetchProducts: async () => {
    set({ isLoading: true, error: null })
    try {
      const products = await productApi.getAll()
      set({ products, isLoading: false })
    } catch (err) {
      set({ error: err.message, isLoading: false })
    }
  }
}))

Für komplexe asynchrone Abläufe empfiehlt der Zustand-Leitfaden zu Async-Patterns, Loading- und Error-States zusammen mit den Daten zu halten, die sie beschreiben.

Zustand v5 Änderungen, die in Interviews vorkommen können

Zustand v5 führte Breaking Changes ein, die Interviewer verwenden, um festzustellen, ob Kandidaten auf dem aktuellen Stand sind:

• Keine Default-Exports mehr: { create } importieren statt create
• Strikteres TypeScript: Das create<T>()()-Muster ersetzt create<T>()
• Synchrone Persist-Hydration: onRehydrateStorage-Callback-Timing hat sich geändert
• CJS-Support eingestellt: Nur noch ESM-Paket

Die Migration von v4 zu v5 erfordert die Aktualisierung von Import-Statements und die Anpassung von Code, der auf dem alten Hydration-Timing basierte.

Kernpunkte für Zustand-Interviews

• Zustand-Stores leben außerhalb des React-Baums und ermöglichen synchronen Zugriff sowie verhindern Provider-Verschachtelung
• Selektoren mit Shallow Comparison optimieren Re-Renders für Produktionsanwendungen
• Die persist-Middleware erfordert partialize um Funktionen vom Storage auszuschließen
• Das Slice-Muster skaliert Zustand für große Anwendungen ohne Typ-Sicherheit zu opfern
• Async-Actions funktionieren direkt ohne Middleware, anders als Redux-Muster
• Testen erfordert explizites State-Zurücksetzen zwischen Testfällen
• Server Components zwingen Zustand an Client-Grenzen, was Architektur-Entscheidungen beeinflusst