Zustand Computed State Middleware

Common errors

• TypeError: store.use is not a function

  cause `computed` was used as a middleware directly, instead of being called as a function, or the wrong import for `create` was used.
  fix Ensure `createComputed` is imported correctly and called as a function (e.g., `create(createComputed(...)(...))`). Also, confirm `create` is imported from 'zustand' as `import { create } from 'zustand'`.

• Property 'computedValue' does not exist on type 'StoreType'.

  cause TypeScript compiler error indicating that the computed properties are not correctly merged into the store's type definition.
  fix Ensure your `create` call is correctly typed to include both your base `Store` type and the `ComputedStore` type. For example: `create<Store, [['chrisvander/zustand-computed', ComputedStore]]>(computed(...))`.

• Error: An Immer producer returned a new value without a change.

  cause Using `zustand-computed` with `immer` middleware where computed state changes are incorrectly handled or trigger unexpected Immer behavior.
  fix Update to `zustand-computed` v2.1.2 or newer to leverage bug fixes specifically for Immer compatibility. Ensure the order of middleware is correct, typically `immer(computed(...))`.

Warnings

• breaking The `computed` middleware was replaced by `createComputed` function. This requires changing your import and how you apply the middleware.
  Fix: Change `import computed from 'zustand-computed'` to `import { createComputed } from 'zustand-computed'`. Update usage from `create(computed(...))` to `create(createComputed(...)(...))`.
• gotcha Earlier versions used a Proxy for computed state, which could lead to unexpected behavior or performance issues in some scenarios. This was removed in v2.1.0.
  Fix: No direct fix needed if upgrading to v2.1.0 or later, as the problematic Proxy behavior has been removed. Ensure your logic doesn't rely on Proxy-specific behaviors.
• gotcha When combining `zustand-computed` with other Zustand middleware like `immer`, compatibility issues (e.g., throwing errors) have been reported and fixed in recent versions.
  Fix: Ensure you are on `zustand-computed` v2.1.2 or newer, which includes specific fixes for Immer compatibility. Review middleware order, typically `immer(computed(...))` or `devtools(immer(computed(...)))`.
• gotcha The internal import path for `zustand` changed from `zustand` to `zustand/vanilla` in a previous version, which could affect bundling or specific environments.
  Fix: No direct user fix is needed for this internal change. However, if you experience bundling issues with older `zustand-computed` versions, ensure you're on a recent version. This was an internal fix.
• gotcha By default, the compute function runs on every store change. For complex computations, this can be inefficient. Optimization options are available.
  Fix: Pass an options object to `createComputed` with `keys` (an array of state keys to watch) or `shouldRecompute` (a function comparing previous and next state) to control when recomputation occurs.

Install

• npm install zustand-computed npm
• yarn add zustand-computed yarn
• pnpm add zustand-computed pnpm

Imports

• createComputed
  wrong:

  import computed from 'zustand-computed' // Breaking change in v2.0.0

  correct:

  import { createComputed } from 'zustand-computed'

  The `computed` middleware was replaced by `createComputed` function in v2.0.0. Ensure you use named import.
• create
  wrong:

  import create from 'zustand'

  correct:

  import { create } from 'zustand'

  While not directly from `zustand-computed`, `create` from `zustand` is essential. In newer Zustand versions, `create` is typically a named export.
• ComputedStore

  type ComputedStore = { countSq: number }

  When using TypeScript, it's recommended to define a specific type for your computed state, separate from your base store state, for clear type inference and safety.

Quickstart

This quickstart demonstrates how to define a Zustand store with computed state using `createComputed`, including TypeScript types, and basic state manipulation. It shows how the computed property (`countSq`) becomes part of the store's observable state and is accessible like any other state property.

import { create } from 'zustand'
import { createComputed } from 'zustand-computed'

type Store = {
  count: number
  inc: () => void
  dec: () => void
}

type ComputedStore = {
  countSq: number
}

const computed = createComputed((state: Store): ComputedStore => ({
  countSq: state.count ** 2,
}))

// To integrate with other middleware like devtools or immer, wrap them around computed
// For example: create<Store>()(devtools(computed(...))) or create<Store>()(immer(computed(...)))

const useStore = create<Store>()(
  computed(
    (set, get) => ({
      count: 1,
      inc: () => set((state) => ({ count: state.count + 1 })),
      dec: () => set((state) => ({ count: state.count - 1 })),
      // get() function inside the store definition has access to both base and computed state
      square: () => set(() => ({ count: get().countSq })),
      root: () => set((state) => ({ count: Math.floor(Math.sqrt(state.count)) })),
    })
  )
)

// Example usage (e.g., in a React component)
function Counter() {
  const { count, countSq, inc, dec } = useStore()
  return (
    <div>
      <span>Count: {count}</span>
      <br />
      <span>Count Squared: {countSq}</span>
      <br />
      <button onClick={inc}>+1</button>
      <button onClick={dec}>-1</button>
    </div>
  )
}

// To demonstrate outside React, for example in Node.js:
const unsubscribe = useStore.subscribe((state) => {
  console.log('Current state:', state.count, 'Computed:', state.countSq);
});

useStore.getState().inc(); // Increment count, triggering recomputation
useStore.getState().inc();

unsubscribe();