intermediate

State Management

Ownership, derivation, normalization, global stores, observable stores, lightweight stores, and server-state caches in frontend applications.

State management interviews test architecture judgment more than library trivia. Strong answers name the source of truth, who owns each value, how long it lives, whether it is canonical or derived, and what synchronization cost you accept.

Child sections cover general principles (local vs global, server vs client, derivation, normalization, immutability), client stores (Redux, MobX, Zustand), and server-state caches (TanStack Query, SWR, invalidation, optimistic UI).

On interviews: expect when local state is enough, when a global store is justified, how Redux differs from MobX or Zustand, and why server-cache libraries are not generic client stores.

Common pitfalls: globalizing every value, duplicating derived data, invisible nested mutation, persisting sensitive fields, and mixing cache freshness with UI ownership.

Checklist:

  • Name the source of truth per value.
  • Choose the smallest owner that works.
  • Derive instead of duplicate.
  • Plan invalidation, persistence, and rollback.