Zustand Sollicitatievragen 2026: React State Management en Best Practices

Zustand heeft zich gevestigd als de favoriete state management-bibliotheek voor React-applicaties die meer nodig hebben dan de Context API maar minder overhead dan Redux. Met zijn minimale API-oppervlak en TypeScript-first ontwerp verschijnen Zustand-vragen regelmatig in frontend-sollicitaties, vooral voor mid-level en senior React-posities.

Essentiële Zustand-Concepten voor Elke Kandidaat

Zustand v5, uitgebracht eind 2024, introduceerde verschillende breaking changes ten opzichte van v4. De create-functie vereist niet langer een aparte useStore-aanroep, en de persist-middleware gebruikt standaard een synchroon hydratiemodel. Interviewers verwachten dat kandidaten de huidige API kennen.

Wat onderscheidt Zustand van useState en useReducer?

Zustand-stores bestaan buiten de React-componentenboom. Dit architecturale verschil heeft drie praktische consequenties:

1. State blijft behouden over component mounts en unmounts zonder Context-providers
2. Updates veroorzaken geen parent re-renders, alleen geabonneerde componenten renderen opnieuw
3. State kan synchroon worden benaderd buiten React, handig voor event handlers en asynchrone logica

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)
}))

De get-functie biedt synchrone toegang tot de huidige state en vermijdt zo het stale closure-probleem dat vaak voorkomt bij useState.

Hoe gaat Zustand om met Re-renders?

Zustand gebruikt standaard shallow equality. Wanneer een component zich abonneert op een store met useCartStore(), ontvangt het het volledige state-object en rendert bij elke wijziging opnieuw. Het selecteren van specifieke slices voorkomt onnodige renders:

// Slecht: rendert bij elke store-wijziging opnieuw
const { items } = useCartStore()

// Goed: rendert alleen opnieuw wanneer items wijzigt
const items = useCartStore((state) => state.items)

// Meerdere waarden: shallow comparison gebruiken
import { shallow } from 'zustand/shallow'

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

De shallow comparator uit zustand/shallow voert referentie-gelijkheid uit op objecteigenschappen in plaats van het object zelf.

Zustand vs Context API: Wanneer Welke Kiezen

Deze vergelijkingsvraag komt voor in bijna elk interview dat state management behandelt. Het antwoord hangt af van de updatefrequentie en state-complexiteit.

De Context API werkt goed voor zelden veranderende waarden zoals thema of locale. Zustand excelleert wanneer state-updates vaak voorkomen, zoals formulierinvoer, real-time data of winkelwagentjes. De React-documentatie over state management raadt aan om state omhoog te tillen en Context te gebruiken voor "prop drilling"-problemen, terwijl externe stores geschikt zijn voor complexe updatepatronen.

Middleware-Patronen in Zustand

Middleware-vragen testen of een kandidaat compositie boven configuratie begrijpt. Zustand-middleware wikkelt de store creator-functie en voegt gedrag toe zonder de kern-API te wijzigen.

Hoe werkt de 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 })
    }
  )
)

De partialize-optie sluit functies en afgeleide state uit van persistentie. Zonder dit faalt de serialisatie of raakt de storage opgeblazen met onnodige data. De Zustand-documentatie over persist behandelt migratiestrategieën voor schema-wijzigingen.

Meerdere middleware combineren

Middleware componeert van binnen naar buiten. De binnenste middleware wordt eerst uitgevoerd:

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 en actions
        }))
      ),
      { name: 'app-storage' }
    ),
    { name: 'AppStore' }
  )
)

De immer-middleware maakt updates in muteerbare stijl mogelijk die immutable state produceren. De subscribeWithSelector-middleware staat toe om te abonneren op state-slices buiten React-componenten.

TypeScript-Integratiepatronen

Zustand v5 heeft de TypeScript-inferentie aanzienlijk verbeterd. Het dubbele functieaanroep-patroon create<Type>()() biedt volledige type-inferentie voor middleware-ketens.

Actions typeren die naar andere state verwijzen

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
    }
  }
}))

Afgeleide state als functies in plaats van getters voorkomt verouderde waarden. Elke aanroep van filteredTodos() leest de huidige state.

Stores splitsen voor grote applicaties

Een veelvoorkomende interviewvraag vraagt hoe Zustand te structureren voor schaalbaarheid. Het slice-patroon splitst een store in domeinmodules:

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,  // Gecombineerd store type
  [],
  [],
  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 kunnen naar elkaar verwijzen via het gecombineerde store type dat aan StateCreator wordt doorgegeven.

Veelvoorkomende Interviewvragen met Modelantwoorden

Wanneer zou Zustand een slechte keuze zijn?

Zustand voegt complexiteit toe zonder voordeel in deze scenario's:

• Statische configuratiegegevens die nooit veranderen tijdens runtime
• Formulierstate beheerd door React Hook Form of vergelijkbare bibliotheken
• Serverstate beter afgehandeld door TanStack Query of SWR
• Eenvoudige parent-child prop-overdracht met 2-3 niveaus van nesting

De vergelijkingssectie in de Zustand GitHub-repository biedt het perspectief van de beheerders op alternatieven.

Hoe worden componenten getest die Zustand gebruiken?

Testen vereist het resetten van de store-state tussen tests en optioneel het volledig mocken van de store:

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

beforeEach(() => {
  // Reset store naar initiële state
  useCartStore.setState({ items: [], totalItems: 0 })
})

test('addItem verhoogt winkelwagentelling', () => {
  const { result } = renderHook(() => useCartStore())
  
  act(() => {
    result.current.addItem({ id: '1', name: 'Product', price: 10 })
  })
  
  expect(result.current.items).toHaveLength(1)
})

Voor componenttests die niet met echte stores moeten interageren, mock op moduleniveau:

import { vi } from 'vitest'

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

Hoe gaat Zustand om met asynchrone operaties?

In tegenstelling tot Redux heeft Zustand geen middleware-vereiste voor async. Actions kunnen direct async-functies zijn:

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 })
    }
  }
}))

Voor complexe asynchrone flows raadt de Zustand-gids over async-patronen aan om loading- en error-states samen te houden met de data die ze beschrijven.

Zustand v5 Wijzigingen Die in Interviews Kunnen Verschijnen

Zustand v5 introduceerde breaking changes die interviewers gebruiken om te bepalen of kandidaten up-to-date zijn:

• Geen default exports meer: Importeer { create } in plaats van create
• Striktere TypeScript: Het create<T>()()-patroon vervangt create<T>()
• Synchrone persist-hydratie: De timing van de onRehydrateStorage-callback is veranderd
• CJS-ondersteuning verwijderd: Alleen ESM-pakket

Migreren van v4 naar v5 vereist het bijwerken van import-statements en het aanpassen van code die vertrouwde op de oude hydratietiming.

Kernpunten voor Zustand-Interviews

• Zustand-stores leven buiten de React-boom, waardoor synchrone toegang mogelijk is en provider-nesting wordt voorkomen
• Selectors met shallow comparison optimaliseren re-renders voor productieapplicaties
• De persist-middleware vereist partialize om functies uit te sluiten van storage
• Het slice-patroon schaalt Zustand voor grote applicaties zonder type safety op te offeren
• Async-actions werken direct zonder middleware, anders dan Redux-patronen
• Testen vereist expliciet state-reset tussen testgevallen
• Server Components dwingen Zustand naar client-boundaries, wat architectuurbeslissingen beïnvloedt