Zustand

When using Zustand in Next.js, you must account for server-side rendering (SSR) and the hybrid routing model. To avoid common issues, follow these core principles:

• Avoid Global Stores: Because a Next.js server handles multiple requests simultaneously, a global Zustand store (module state) would be shared across different users' requests. Instead, create a store per request using a factory function.
• Use React Context for Client-side State: To ensure the store is reset during SPA routing and to avoid hydration errors, initialize the store at the component level using a Context provider.
• Do not use Zustand in React Server Components (RSC): RSCs cannot use hooks or context and are not meant to be stateful. They should not read from or write to a Zustand store.
• Server Caching Compatibility: Zustand's module state is compatible with Next.js App Router's aggressive server caching.

Zustand v5 enforces stricter selector behavior to align with React. If a selector returns a new object or array reference on every call, it can trigger infinite re-render loops.

To fix this, ensure your selectors return stable references using one of these methods:

1. Use useShallow: Wrap selectors that return new arrays or objects in useShallow to ensure the reference only changes when the actual content changes.
2. Use stable fallbacks: If a selector returns a function or an object that might be undefined, provide a constant fallback instead of an inline anonymous function.
3. Use createWithEqualityFn: If you need to revert to the v4 behavior where unstable references were handled differently, use createWithEqualityFn from zustand/traditional.

import { useShallow } from 'zustand/shallow'

// Fix for array/object selectors
const [searchValue, setSearchValue] = useStore(
  useShallow((state) => [state.searchValue, state.setSearchValue])
)

// Fix for function selectors
const FALLBACK_ACTION = () => {}
const action = useMainStore((state) => state.action ?? FALLBACK_ACTION)

When building complex state logic, avoid storing values that can be calculated from existing state. This prevents bugs where different parts of the state get out of sync.

In the Tic-Tac-Toe tutorial, xIsNext (which indicates if it is X's turn) is directly tied to whether the currentMove is even or odd. Instead of storing xIsNext in the Zustand store and manually updating it via setXIsNext, you should calculate it inside your component as a derived value.

Benefits:

• Reduces the number of state updates required.
• Eliminates the possibility of xIsNext and currentMove becoming desynchronized.
• Simplifies the store logic and setter functions.

export default function Game() {
  const history = useGameStore((state) => state.history)
  const currentMove = useGameStore((state) => state.currentMove)
  
  // Derived state: calculated during render, not stored in Zustand
  const xIsNext = currentMove % 2 === 0
  const currentSquares = history[currentMove]

  // ...
}

Instead of having a component manage its own local state, you can make it 'controlled' by passing state and update callbacks as props. This pattern allows the parent component (or the Zustand store) to act as the single source of truth.

1. The Child Component: Receives values (e.g., squares, xIsNext) and an event handler (e.g., onPlay) via props. It calls the handler instead of updating local state.
2. The Parent Component: Selects the necessary state from the Zustand store using hooks and implements the logic to update the store when the child's handler is triggered.

// Controlled Child
function Board({ xIsNext, squares, onPlay }) {
  function handleClick(i) {
    const nextSquares = squares.slice()
    nextSquares[i] = xIsNext ? 'X' : 'O'
    onPlay(nextSquares)
  }
  // ... render logic
}

// Parent managing store updates
function Game() {
  const history = useGameStore((state) => state.history)
  const setHistory = useGameStore((state) => state.setHistory)
  
  function handlePlay(nextSquares) {
    setHistory(history.concat([nextSquares]))
  }

  return <Board squares={history[history.length - 1]} onPlay={handlePlay} />
}

function Board({ xIsNext, squares, onPlay }) {
  const winner = calculateWinner(squares)
  const turns = calculateTurns(squares)
  const player = xIsNext ? 'X' : 'O'
  const status = calculateStatus(winner, turns, player)

  function handleClick(i) {
    if (squares[i] || winner) return
    const nextSquares = squares.slice()
    nextSquares[i] = player
    onPlay(nextSquares)
  }

  return (
    <>
      <div style={{ marginBottom: '0.5rem' }}>{status}</div>
      <div style={{ display: 'grid', gridTemplateColumns: 'repeat(3, 1fr)' }}>
        {squares.map((square, squareIndex) => (
          <Square
            key={squareIndex}
            value={square}
            onSquareClick={() => handleClick(squareIndex)}
          />
        ))}
      </div>
    </>
  )
}

Zustand and Redux both use an immutable state model. A key difference is that Redux requires your application to be wrapped in context providers, whereas Zustand does not.

In both libraries, render optimization is achieved by manually applying selectors to extract only the necessary parts of the state.

import { create } from 'zustand'

type State = {
  count: number
}

type Actions = {
  increment: (qty: number) => void
  decrement: (qty: number) => void
}

const useCountStore = create<State & Actions>((set) => ({
  count: 0,
  increment: (qty: number) => set((state) => ({ count: state.count + qty })),
  decrement: (qty: number) => set((state) => ({ count: state.count - qty })),
}))

const Component = () => {
  const count = useCountStore((state) => state.count)
  const increment = useCountStore((state) => state.increment)
  const decrement = useCountStore((state) => state.decrement)
  // ...
}