Zustand interview questions and answers

Zustand is a small, fast state-management library for React built on hooks. You create a store with create((set, get) => ({ ...state, ...actions })) and read it with the returned hook. There are no providers, reducers or boilerplate, components re-render only for the slices they select, and it works outside React too. It suits shared client state in apps that do not need Redux's structure.

Calling useStore(state => state.count) subscribes the component only to count; it re-renders when that value changes by Object.is. Selecting the whole store re-renders on every change. For selecting several values as an object or array, use useShallow so a new object with equal fields does not trigger a render.

Call set with a partial object or a function of the current state: set(state => ({ count: state.count + 1 })). Zustand shallow-merges the top level; nested objects must be copied (or use the Immer middleware). get() reads current state inside actions.

create builds a store: a state object with setState, getState and subscribe. The React hook uses useSyncExternalStore to subscribe a component to the result of its selector, re-rendering only when that result changes (by Object.is).

Actions are just functions, so make them async: set a loading flag, await the request, then set the result or error. No middleware is needed. For server data that needs caching and refetching, TanStack Query is usually a better fit.

Client state shared across components: UI preferences, auth session details, wizards, editor state, carts. Server data with caching needs is better in TanStack Query; form input state is better in a form library; URL-shareable state belongs in search params.

persist saves state to storage (localStorage, sessionStorage, AsyncStorage) with versioning and migrations; devtools connects to Redux DevTools; immer allows mutable-style updates; subscribeWithSelector subscribes to slices outside React; combine infers types from initial state. Middlewares are composed by wrapping the creator.

Use the slices pattern: write separate slice creators (createBearSlice, createFishSlice) that each return part of the state and actions, and combine them in one create. Or use several independent stores for unrelated features. Keep actions in the store, next to the state they change.

A module-level store is shared across requests on the server, which can leak data between users. For per-request state, create the store inside a component with createStore (vanilla) and provide it through React context, reading with useStore(storeFromContext, selector). Keep server data in Server Components or TanStack Query.

Context is built in and fine for rarely changing values, but every consumer re-renders when the value changes. Zustand gives selective subscriptions with minimal code. Redux Toolkit adds strong conventions, middleware, DevTools time travel and RTK Query, which helps large teams. Server data belongs in a data-fetching library in all cases.

Keep the initial state in a constant and add a reset: () => set(initialState) action. For tests, a common pattern resets all stores in afterEach by recording each store's initial state when created.

Call useStore.subscribe(listener) to run code on every change, or use the subscribeWithSelector middleware to subscribe to a selected slice with an equality function and fireImmediately option. Unsubscribe with the returned function.

Wrap the creator with immer(...); then set(state => { state.todos.push(todo) }) can mutate a draft and Immer produces the immutable update. It simplifies deep nested updates.

Nest them, typically devtools(persist(immer(creator), { name })), with devtools outermost so it records actions after other middleware. In TypeScript, use the curried create<State>()(...) form so types infer correctly.

For per-component or per-request stores, create a vanilla store with createStore in a provider (in a ref or useState), pass it through context, and read it with useStore(storeFromContext, selector). This is the recommended pattern for SSR in Next.js.

Set version in persist options and provide a migrate(persistedState, version) function that transforms old shapes into the new one, so users' saved data keeps working after a release.

On load it reads storage and merges saved state into the store; in SSR the first render may show the default state, then the persisted one, causing hydration mismatches. Use onRehydrateStorage or persist.hasHydrated() to wait, render persisted UI only on the client, and use partialize to save only what is needed, with version and migrate for schema changes.

The hook returned by create also exposes getState(), setState() and subscribe(), so you can read or change state from event handlers, utilities or tests. createStore from zustand/vanilla makes a store with no React dependency.

Reset the store between tests (save the initial state and call setState(initial, true) in afterEach), or mock the module as the docs show, then test behaviour through the UI. Pure store logic can be tested directly with getState().

Declare the state and actions in an interface and call create<State>()((set) => ({ ... })); the extra parentheses (currying) let TypeScript infer middleware types correctly.

Read the latest state inside actions with get() instead of values captured from render, and in callbacks outside React use useStore.getState().

Zustand is a single store (or several) accessed with selectors, top-down. Jotai builds state from small atoms combined bottom-up, closer to React's model. Both are small and from the same open-source collective (pmndrs).

Subscribe to the store in an effect and update a ref or the DOM directly in the listener, instead of selecting the value in render. This suits high-frequency values like mouse position or animation frames.

Write slice creators (createBearSlice = (set, get) => ({...})), each in its own file, and combine them in create((...a) => ({ ...createBearSlice(...a), ...createFishSlice(...a) })), typing them with StateCreator.

Stores expose getInitialState(), returning the state the store was created with, useful for resets and for server rendering snapshots.

Use the devtools middleware with Redux DevTools to see actions and state over time, name actions in set(partial, false, 'todos/add'), and log changes with a simple subscribe.

Compute them in selectors (useStore(s => s.items.length)) or helper functions, rather than storing duplicates that can go out of sync. For expensive derivations, memoise the selector.

No. Stores are module-level hooks by default. A provider and context are only needed when you want a separate store per component tree or per request.

A helper that wraps a selector returning an object or array and compares the result shallowly, so the component only re-renders when one of the selected values changes.

Yes. zustand/vanilla's createStore creates a framework-independent store with get, set and subscribe, which other frameworks or plain JavaScript can use.

1. AmakeStore
2. BconfigureStore
3. CcreateStore only
4. DcreateCorrect answer

Why: create returns a hook bound to the store.

1. AuseStore()
2. BuseStore(s => s.count)Correct answer
3. CuseContext(Store)
4. Dstore.watch('count')

Why: Selectors limit re-renders to that slice.

1. AOnly in production
2. BOnly with TypeScript
3. CYes, always
4. DNoCorrect answer

Why: Stores work without providers.

1. AuseSyncExternalStoreCorrect answer
2. BuseEffect only
3. CuseContext
4. DuseReducer

Why: Safe with concurrent rendering.

1. AAn async function that calls setCorrect answer
2. BA special async middleware
3. CThunks only
4. DIt is not possible

Why: Actions are plain functions.

1. ATheme preference
2. BSidebar open state
3. CWizard step
4. DCached server dataCorrect answer

Why: Query handles caching and refetching.

1. Acombine
2. Bdevtools
3. CpersistCorrect answer
4. Dimmer

Why: persist writes to a storage engine.

1. AShallow-merges it at the top levelCorrect answer
2. BDeep-merges every level
3. CIgnores it
4. DReplaces the whole state

Why: Nested objects must be copied manually or with Immer.

1. AuseShallowCorrect answer
2. BuseDeep
3. CuseCallback
4. DuseMemo

Why: It compares the selected object shallowly.

1. Aredux
2. BdevtoolsCorrect answer
3. Clogger
4. Dpersist

Why: devtools enables inspection and time travel.

1. Acombine
2. BsubscribeWithSelectorCorrect answer
3. Cpersist
4. Ddevtools

Why: With an equality function.

1. Acreate(...) as State
2. BcreateStore<any>
3. Ccreate<State>(...)
4. Dcreate<State>()(...)Correct answer

Why: The curried form infers correctly.

1. AOne global module store
2. BlocalStorage
3. CCookies only
4. DA per-request store via contextCorrect answer

Why: Avoids sharing state between users.

1. AonRehydrateStorage
2. Bmigrate with versionCorrect answer
3. Cpartialize
4. Dstorage

Why: Transforms old shapes.

1. AOrder never matters
2. Bdevtools(persist(immer(...)))Correct answer
3. Cimmer(devtools(...)) only
4. Dpersist outermost always

Why: Devtools outermost.

1. AReact.getStore()
2. BuseStore.getState()Correct answer
3. CuseStore.read()
4. Dstore.current

Why: getState returns the current state.

1. AIt is slow
2. BIt can share state between requests and usersCorrect answer
3. CIt cannot be typed
4. DIt breaks CSS

Why: Server modules live across requests.

1. ApartializeCorrect answer
2. Bfilter
3. Cpick
4. Dinclude

Why: partialize selects the persisted slice.

1. ASplit CSS
2. BSplit routes
3. CShard databases
4. DSplit one large store into combinable partsCorrect answer

Why: Each slice creator returns part of the store.

1. Athis.state
2. Bprops
3. Cget()Correct answer
4. DuseStore() inside the action

Why: Avoids stale closures.

1. AJotaiCorrect answer
2. BRedux
3. CMobX
4. DXState

Why: Bottom-up state.

1. ATransient updates via subscribe and refsCorrect answer
2. BSelect it in render
3. CUse context
4. DUse useState

Why: Avoids render cost.

1. AStoreApi only
2. BCreator
3. CStateCreatorCorrect answer
4. DSliceType

Why: From zustand.

1. ANames the action for devtoolsCorrect answer
2. BReplaces state
3. CPersists state
4. DLogs errors

Why: With devtools middleware.

1. AmakeStore
2. BcreateStore from zustand/vanillaCorrect answer
3. Ccreate from zustand
4. DuseStore

Why: Framework-independent.

1. Azustand/vanilla createStoreCorrect answer
2. Bzustand/react
3. Czustand/server
4. Dzustand/node

Why: Vanilla stores have no React dependency.

1. Apersist
2. Bdevtools
3. Ccombine
4. DimmerCorrect answer

Why: Immer produces immutable updates from mutations.

1. AAbout 1 KB gzippedCorrect answer
2. BAbout 100 KB
3. CAbout 1 MB
4. DAbout 10 MB

Why: It is a tiny library.

1. ARedux team
2. BThe pmndrs collectiveCorrect answer
3. CMeta
4. DVercel

Why: Also Jotai and Valtio.

1. AReload the page
2. Bdelete the store
3. CuseStore.clear()
4. Dset(initialState) in a reset actionCorrect answer

Why: Keep initial state in a constant.