Zustand for client state in NextJS - Performance & Optimization

Performance: Zustand for client state

MEDIUM IMPACT

This affects how fast the page responds to user actions and how efficiently the UI updates without unnecessary delays.

Managing client state efficiently in a Next.js app

NextJS

import { create } from 'zustand';

const useStore = create(set => ({
  count: 0,
  increment: () => set(state => ({ count: state.count + 1 }))
}));

function Counter() {
  const count = useStore(state => state.count);
  const increment = useStore(state => state.increment);
  return (
    <div>
      <button onClick={increment}>Increment</button>
      <p>{count}</p>
    </div>
  );
}

export default Counter;

Zustand updates only components that use the changed state slice, reducing re-renders and improving responsiveness.

📈 Performance GainSingle re-render per state change, improving INP and reducing CPU usage.

Managing client state efficiently in a Next.js app

NextJS

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <p>{count}</p>
    </div>
  );
}

export default Counter;

Using local useState in many components causes repeated state duplication and unnecessary re-renders across unrelated parts.

📉 Performance CostTriggers multiple re-renders and can cause slower interaction responsiveness as app scales.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Local useState in many components	Multiple updates across components	Multiple reflows per update	Higher paint cost due to many re-renders	[X] Bad
Zustand with selective subscriptions	Minimal updates only where needed	Single reflow per update	Lower paint cost with fewer re-renders	[OK] Good

Rendering Pipeline

Zustand updates state outside React's local state, then triggers selective React component re-renders only where state is used.

→JavaScript Execution

→React Reconciliation

→Paint

→Composite

⚠️ BottleneckReact Reconciliation when many components re-render unnecessarily

Core Web Vital Affected

INP

This affects how fast the page responds to user actions and how efficiently the UI updates without unnecessary delays.

Optimization Tips

1Use Zustand selectors to subscribe only to needed state slices.

2Avoid updating global state unnecessarily to reduce re-renders.

3Profile React components to ensure minimal re-render on state changes.

Performance Quiz - 3 Questions

How does Zustand improve interaction responsiveness compared to local useState?

A By batching all state updates into one global update

B By updating only components subscribed to changed state slices

C By forcing full page reload on state change

D By storing state on the server instead of client

DevTools: React DevTools Profiler

How to check: Record interactions and observe component re-render counts and durations when state changes.

What to look for: Look for fewer component re-renders and shorter render times indicating efficient state updates.

Practice

1. What is the main purpose of using zustand in a Next.js app?

easy

A. To manage and share client-side state easily across components

B. To handle server-side rendering automatically

C. To style components with CSS-in-JS

D. To fetch data from external APIs

Solution

1. Step 1: Understand Zustand's role

   Zustand is a small library designed to manage state on the client side simply and clearly.

2. Step 2: Compare options with Zustand's purpose

   Only To manage and share client-side state easily across components matches Zustand's main use: managing and sharing client state across components.

3. Final Answer:

   To manage and share client-side state easily across components -> Option A

4. Quick Check:

   Zustand = client state management [OK]

Hint: Zustand is for client state, not styling or server tasks [OK]

Common Mistakes:

• Confusing Zustand with data fetching libraries
• Thinking Zustand handles styling
• Assuming Zustand manages server rendering

2. Which of the following is the correct way to create a Zustand store in Next.js?

easy

A. const useStore = createStore((get) => ({ count: 0, increment: () => get(state => state.count + 1) }))

B. const useStore = createStore({ count: 0, increment() { this.count++ } })

C. const useStore = new Zustand({ count: 0, increment() { this.count++ } })

D. const useStore = create((set) => ({ count: 0, increment: () => set(state => ({ count: state.count + 1 })) }))

Solution

1. Step 1: Recall Zustand store creation syntax

   Zustand uses the create function with a callback receiving set to update state.

2. Step 2: Check each option's syntax

   const useStore = create((set) => ({ count: 0, increment: () => set(state => ({ count: state.count + 1 })) })) correctly uses create with set and updates state immutably. Others use invalid or non-existent APIs.

3. Final Answer:

   const useStore = create((set) => ({ count: 0, increment: () => set(state => ({ count: state.count + 1 })) })) -> Option D

4. Quick Check:

   Use create + set callback = const useStore = create((set) => ({ count: 0, increment: () => set(state => ({ count: state.count + 1 })) })) [OK]

Hint: Zustand store uses create() with set callback [OK]

Common Mistakes:

• Using createStore instead of create
• Trying to mutate state directly
• Confusing get and set functions

3. Given this Zustand store code:

const useStore = create(set => ({ count: 0, increment: () => set(state => ({ count: state.count + 1 })) }));
useStore.getState().increment();
console.log(useStore.getState().count);

What will be logged to the console?

medium

A. 1

B. Error

C. undefined

D. 0

Solution

1. Step 1: Understand initial state and increment call

   The store starts with count = 0. Calling increment() increases count by 1.

2. Step 2: Check console.log output

   After increment(), count becomes 1, so logging count outputs 1.

3. Final Answer:

   1 -> Option A

4. Quick Check:

   Increment changes count 0 -> 1 [OK]

Hint: Increment adds 1, so count becomes 1 [OK]

Common Mistakes:

• Assuming state doesn't update immediately
• Confusing getState() with useStore() hook
• Expecting initial value without increment

4. Identify the error in this Zustand store code:

const useStore = create(set => ({
  count: 0,
  increment() {
    this.count += 1;
  }
}));

medium

A. Missing initial state declaration

B. Using this inside increment does not update Zustand state

C. The create function is not imported

D. The increment function should be async

Solution

1. Step 1: Analyze increment function behavior

   Using this.count += 1 tries to mutate the object directly, which does not update Zustand's internal state.

2. Step 2: Understand correct state update in Zustand

   Zustand requires calling set to update state immutably; direct mutation won't trigger updates.

3. Final Answer:

   Using this inside increment does not update Zustand state -> Option B

4. Quick Check:

   Direct mutation with this = no state update [OK]

Hint: Always use set() to update Zustand state, not this [OK]

Common Mistakes:

• Mutating state directly with this
• Forgetting to import create
• Thinking async is needed for increment

5. You want to create a Zustand store that holds a list of tasks and a function to add a new task only if it is not empty. Which code snippet correctly implements this logic?

hard

A. const useStore = create(set => ({ tasks: [], addTask: (task) => set(state => ({ tasks: [...state.tasks, task] })) }))

B. const useStore = create(set => ({ tasks: [], addTask: (task) => { if (!task) set(state => ({ tasks: [...state.tasks, task] })) } }))

C. const useStore = create(set => ({ tasks: [], addTask: (task) => { if (!task) return; set(state => ({ tasks: [...state.tasks, task] })) } }))

D. const useStore = create(set => ({ tasks: [], addTask: (task) => set(state => { if (!task) return { tasks: [...state.tasks, task] } else return state }) }))

Solution

1. Step 1: Understand the requirement to add task only if not empty

   The function must check if the task is empty and skip adding if so.

2. Step 2: Analyze each option's logic

   const useStore = create(set => ({ tasks: [], addTask: (task) => set(state => ({ tasks: [...state.tasks, task] })) })) adds unconditionally.
   const useStore = create(set => ({ tasks: [], addTask: (task) => { if (!task) set(state => ({ tasks: [...state.tasks, task] })) } })) adds only if !task (when empty).
   const useStore = create(set => ({ tasks: [], addTask: (task) => set(state => { if (!task) return { tasks: [...state.tasks, task] } else return state }) })) adds only if !task inside the set updater.
   const useStore = create(set => ({ tasks: [], addTask: (task) => { if (!task) return; set(state => ({ tasks: [...state.tasks, task] })) } })) correctly returns early if !task (empty), then calls set to add non-empty task.

3. Final Answer:

   const useStore = create(set => ({ tasks: [], addTask: (task) => { if (!task) return; set(state => ({ tasks: [...state.tasks, task] })) } })) -> Option C

4. Quick Check:

   Early return on empty task + set call = const useStore = create(set => ({ tasks: [], addTask: (task) => { if (!task) return; set(state => ({ tasks: [...state.tasks, task] })) } })) [OK]

Hint: Return early if empty, then call set to update state [OK]

Common Mistakes:

• Adding tasks without checking if empty
• Misusing set callback with conditional returns
• Not returning early to prevent adding empty tasks