State Management Architecture

1The reframe — it's a taxonomy, not a library choice

The junior question is “Redux or Zustand?” The Lead question is “what kind of state am I holding, and what's the right tool for that?” Almost all app state falls into five concerns, each with a different owner and lifecycle: [developerway]

The punchline: most of what teams shove into a global store is actually server state or URL state in disguise. Pull those out into purpose-built tools and the “global state” you have left is small, predictable, and easy to reason about. “Break your state into different concerns and you'll find yourself with better solutions.”

2The big one — server state ≠ client state

This is the distinction the panel is fishing for. Client state you own: it's synchronous, lives in the browser, and you're the source of truth (is the modal open?). Server state you don't own — it's a cache of someone else's data: [Kent C. Dodds]

Putting server data in Redux/Zustand means hand-reinventing caching, request dedupe, background refetch, and invalidation — badly. That's why ~80% of the Redux in legacy apps is just server-state plumbing. A server-state library (TanStack Query / SWR) gives you all of it for free: stale-while-revalidate, dedupe, invalidate-on-mutation (Lesson 08). [TanStack]

// Server state — NOT useState/Redux. The library owns the cache.
const { data, isLoading } = useQuery({
  queryKey: ['hotel', id],          // cache key
  queryFn: () => fetchHotel(id),    // dedupe + SWR + retry, free
});

3The underused one — URL state

The category most engineers forget — and the one that matters most for a travel/booking site. Anything that should survive a refresh, be shareable, bookmarkable, work with the back button, and be crawlable by Google belongs in the URL, not React state: search terms, dates, filters, sort, pagination, the active tab. [developerway]

For the platform this is huge: /search?city=tokyo&checkin=…&guests=2 must be a real, linkable, SEO-indexable URL (Lesson 09). The catch is manually syncing state ↔ URL is “a journey full of misery and weird bugs.” nuqs makes a query param behave like useState: [nuqs]

// The URL IS the state — shareable, refresh-proof, crawlable.
const [city, setCity] = useQueryState('city');   // nuqs — syncs to ?city=

4Local & shared — and the Context trap

What's left after server + URL is genuine client state, and you escalate only as far as you need: [react.dev]

1. Local → useState / useReducer. Most UI state never needs to leave its component. “Zero reason to introduce a library” for a dropdown's open flag.
2. Shared, shallow → prop drilling is fine for 2–3 levels. Lift state to the nearest common parent (colocation).
3. Shared, deep → Context to skip the drilling — but mind the perf trap below.

5The client-store landscape — Zustand vs Jotai vs Redux

Only now — for client state that's shared, changes often, and is read selectively — does a store earn its place. The three you must compare: [Zustand]

“No provider” — what that actually means

A provider exists to inject a value into the React tree so descendants can read it via Context. Zustand never enters the tree: create() builds the store as a plain module-level closure — a normal JS object living in the module's scope. Any component that imports the hook subscribes directly to that external object (Zustand uses React's useSyncExternalStore under the hood). There's nothing to “provide” because the store isn't scoped to a subtree — it's a singleton the module already holds.

// store.js — the store IS a module-scoped object. No <Provider> anywhere.
import { create } from 'zustand';

export const useCartStore = create((set) => ({
  items: [],
  addItem: (item) => set((s) => ({ items: [...s.items, item] })),
  clear:   () => set({ items: [] }),
}));

// CartBadge.jsx — import the hook anywhere; nothing wraps these components.
import { useCartStore } from './store';

function CartBadge() {
  // selector → re-renders ONLY when items.length changes
  const count = useCartStore((s) => s.items.length);
  return <span>🛒 {count}</span>;
}

// AddButton.jsx — somewhere else entirely in the tree, no shared ancestor needed
function AddButton({ product }) {
  const addItem = useCartStore((s) => s.addItem); // stable, never re-renders
  return <button onClick={() => addItem(product)}>Add</button>;
}

Contrast with Context, where you must wrap — <CartContext.Provider value={…}>…</CartContext.Provider> — and only descendants can read. Here CartBadge and AddButton share no provider ancestor; they just both import useCartStore.

The criteria that pick a winner (Makarevich's): simplicity, zero/single provider (no providers hell), granular re-rendering (selectors/atoms, not whole-tree), and React-aligned (hooks, SSR, RSC, unidirectional). On those, Zustand is the common default — “not because it's objectively best, but because it satisfies the criteria.” The modern default stack: TanStack Query + nuqs + Zustand.

6The Platform angle & Lead framing

Apply the taxonomy to a hotel search/booking flow and watch the “global store” shrink to almost nothing:

7Check yourself — scenario quiz

Pick an answer; instant feedback. Push-back style, like the round.