Zustand でミドルウェアを組み合わせる際、その順序を間違えると予期しない動作やエラーが発生してしまいます。この記事では、logger、persist、immer、subscribeWithSelector という 4 つの代表的なミドルウェアを安全に合成する方法を、実践的なコード例とともにご紹介いたしますね。

ミドルウェアの合成順序は一見些細に思えるかもしれませんが、実は状態管理の品質を大きく左右する重要なポイントなのです。

ミドルウェア早見表

各ミドルウェアの役割と特徴を簡潔にまとめました。

#	ミドルウェア名	主な役割	適用位置	重要度
1	logger	状態変更のログ出力	最外層（一番外側）	★★☆
2	persist	状態の永続化（localStorage 等）	logger の次	★★★
3	immer	イミュータブルな状態更新	persist の次	★★★
4	subscribeWithSelector	セレクター単位での購読	最内層（一番内側）	★★☆

推奨される合成順序

#	合成パターン	説明
1	logger(persist(immer(subscribeWithSelector(...))))	全てのミドルウェアを使用する場合の推奨順序
2	persist(immer(...))	永続化とイミュータブル更新のみ使用
3	logger(persist(...))	ログ出力と永続化のみ使用
4	immer(subscribeWithSelector(...))	イミュータブル更新と選択的購読のみ使用

合成時の注意点

#	注意事項	理由
1	logger は必ず最外層に配置	全ての状態変更を監視するため
2	persist は immer より外側に配置	シリアライズ前の状態を保存するため
3	subscribeWithSelector は最内層に配置	状態の購読機能を提供する基盤となるため
4	TypeScript 使用時は型推論に注意	ミドルウェアの順序により型が変わる

背景

Zustand のミドルウェアとは

Zustand は、React アプリケーションで使用される軽量な状態管理ライブラリです。その最大の特徴は、ミドルウェアという拡張機能を使って、状態管理に様々な機能を追加できることでしょう。

ミドルウェアは、ストアの作成時に状態管理の振る舞いを拡張する仕組みです。例えば、状態の変更履歴を記録したり、データを永続化したり、不変性を保証したりすることができます。

以下の図は、Zustand のストアとミドルウェアの関係を示しています。

mermaidCopy codeflowchart TB
  app["React アプリケーション"] -->|状態を利用| store["Zustand ストア"]
  store -->|拡張| mw1["logger<br/>ミドルウェア"]
  store -->|拡張| mw2["persist<br/>ミドルウェア"]
  store -->|拡張| mw3["immer<br/>ミドルウェア"]
  store -->|拡張| mw4["subscribeWithSelector<br/>ミドルウェア"]

  mw1 -.->|ログ出力| console["開発者ツール"]
  mw2 -.->|永続化| storage["localStorage"]
  mw3 -.->|不変性保証| state["State"]
  mw4 -.->|選択的購読| components["コンポーネント"]

この図から分かるように、各ミドルウェアは異なる役割を持ち、ストアの機能を多角的に強化してくれます。

主要な 4 つのミドルウェアの役割

それぞれのミドルウェアが持つ独自の機能を理解することが、適切な合成順序を決定する第一歩となります。

logger ミドルウェア

logger ミドルウェアは、状態の変更をコンソールに出力する開発支援ツールです。

どのアクションがいつ実行され、状態がどう変化したのかを視覚的に確認できるため、デバッグ作業が格段に楽になりますね。

persist ミドルウェア

persist ミドルウェアは、状態を localStorage や sessionStorage に自動保存します。

ページをリロードしても状態が保持されるため、ユーザー体験の向上に大きく貢献してくれるでしょう。

immer ミドルウェア

immer ミドルウェアは、Immer.js を活用して、ミュータブルな記法で不変性を保証します。

複雑なネストした状態でも、直感的なコードで安全に更新できるのが魅力です。

subscribeWithSelector ミドルウェア

subscribeWithSelector ミドルウェアは、状態の特定部分だけを監視する機能を提供します。

不要な再レンダリングを防ぎ、パフォーマンスを最適化できますね。

課題

ミドルウェア合成の順序問題

複数のミドルウェアを組み合わせる際、最も頭を悩ませるのが「どの順序で適用すべきか」という問題です。

ミドルウェアは関数の合成によって動作するため、その順序によって処理の流れが大きく変わってしまいます。間違った順序で適用すると、以下のような問題が発生する可能性があるのです。

以下の図は、誤った合成順序がどのような問題を引き起こすかを示しています。

mermaidCopy codeflowchart TD
  start["ミドルウェアの<br/>誤った合成"] -->|パターン1| issue1["型エラーが発生"]
  start -->|パターン2| issue2["永続化が<br/>正しく動作しない"]
  start -->|パターン3| issue3["ログが不完全"]
  start -->|パターン4| issue4["セレクターが<br/>機能しない"]

  issue1 --> result["開発時の<br/>トラブル"]
  issue2 --> result
  issue3 --> result
  issue4 --> result

  result -->|影響| trouble1["デバッグ困難"]
  result -->|影響| trouble2["予期しない動作"]
  result -->|影響| trouble3["パフォーマンス低下"]

図で理解できる要点：

• 合成順序の誤りは複数の問題を同時に引き起こす
• 各問題が開発効率やユーザー体験に悪影響を与える
• 適切な順序の理解が根本的な解決策となる

よくある失敗パターン

実際の開発現場で遭遇しやすい失敗例を見てみましょう。

失敗例 1：persist を最外層に配置

以下のコードは、一見問題なさそうに見えますが、実は大きな問題を抱えています。

typescriptCopy codeimport { create } from 'zustand';
import { persist } from 'zustand/middleware';
import { logger } from 'zustand/middleware';

上記のインポート文で、必要なミドルウェアを読み込みます。

typescriptCopy code// ❌ 間違った例：persist が最外層
const useStore = create(
  persist(
    logger((set) => ({
      count: 0,
      increment: () =>
        set((state) => ({ count: state.count + 1 })),
    })),
    { name: 'counter-storage' }
  )
);

このコードでは persist を最外層に配置しているため、logger による状態変更のログが localStorage に保存されてしまう可能性があります。

失敗例 2：immer を persist より外側に配置

次の例は、immer と persist の順序が逆になっています。

typescriptCopy codeimport { create } from 'zustand';
import { persist } from 'zustand/middleware';
import { immer } from 'zustand/middleware/immer';

typescriptCopy code// ❌ 間違った例：immer が persist より外側
const useStore = create(
  immer(
    persist(
      (set) => ({
        user: { name: '', age: 0 },
        setName: (name: string) =>
          set((state) => {
            state.user.name = name; // immer の draft 状態
          }),
      }),
      { name: 'user-storage' }
    )
  )
);

この順序だと、immer の draft オブジェクトがシリアライズされようとして、エラーが発生してしまうのです。

失敗例 3：subscribeWithSelector の配置ミス

subscribeWithSelector を外側に配置すると、他のミドルウェアの機能が制限される場合があります。

typescriptCopy code// ❌ 間違った例：subscribeWithSelector が外側
const useStore = create(
  subscribeWithSelector(
    persist(
      (set) => ({
        count: 0,
        increment: () =>
          set((state) => ({ count: state.count + 1 })),
      }),
      { name: 'counter' }
    )
  )
);

このような配置では、セレクターの購読機能が期待通りに動作しない可能性があります。

TypeScript における型の問題

TypeScript を使用している場合、ミドルウェアの合成順序は型推論にも影響を与えます。

誤った順序では、型エラーが頻発し、本来持つべき型安全性が損なわれてしまうでしょう。特に、persist ミドルウェアは型情報の伝播に影響を与えやすく、注意が必要です。

解決策

ミドルウェア合成の黄金律

複数のミドルウェアを安全に組み合わせるには、明確な原則に従う必要があります。

最も重要なのは、「外側から内側へ、処理の流れを意識して配置する」という考え方です。以下の図は、推奨される合成順序を視覚化したものとなります。

mermaidCopy codeflowchart LR
  action["状態変更<br/>アクション"] --> layer1["logger<br/>（最外層）"]
  layer1 -->|ログ記録後| layer2["persist<br/>（2層目）"]
  layer2 -->|永続化後| layer3["immer<br/>（3層目）"]
  layer3 -->|不変性保証後| layer4["subscribeWithSelector<br/>（最内層）"]
  layer4 --> core["コアストア<br/>（状態本体）"]

  core -.->|変更通知| layer4
  layer4 -.->|購読通知| layer3
  layer3 -.->|更新通知| layer2
  layer2 -.->|保存通知| layer1
  layer1 -.->|ログ出力| action

図で理解できる要点：

• 状態変更は外側から内側へ流れる
• 変更通知は内側から外側へ伝播する
• 各層が明確な責務を持つ

推奨される合成順序

実践的な合成順序は、次のようになります。

基本形：全てのミドルウェアを使用する場合

4 つ全てのミドルウェアを使用する場合の標準的な構成をご紹介します。

typescriptCopy codeimport { create } from 'zustand';
import {
  devtools,
  persist,
  subscribeWithSelector,
} from 'zustand/middleware';
import { immer } from 'zustand/middleware/immer';

まず、必要な全てのミドルウェアをインポートします。

typescriptCopy code// ✅ 推奨される合成順序
const useStore = create(
  devtools(
    // 1. 最外層：開発者ツール連携
    persist(
      // 2. 永続化
      immer(
        // 3. 不変性保証
        subscribeWithSelector(
          // 4. 最内層：選択的購読
          (set) => ({
            // ストアの状態と更新関数
            count: 0,
            user: { name: '', email: '' },
            increment: () =>
              set((state) => {
                state.count += 1;
              }),
            setUser: (name: string, email: string) =>
              set((state) => {
                state.user.name = name;
                state.user.email = email;
              }),
          })
        )
      ),
      { name: 'app-storage' }
    )
  )
);

この順序が推奨される理由を、各層ごとに説明いたしますね。

レイヤー 1：logger / devtools（最外層）

logger や devtools は、全ての状態変更を監視する必要があるため、最外層に配置します。

typescriptCopy code// logger を最外層に配置する理由
devtools(
  // この内側で起きる全ての変更を監視
  persist(/* ... */)
);

こうすることで、persist による復元や immer による更新も含め、全ての状態変更をログに記録できます。

レイヤー 2：persist（2 層目）

persist は、シリアライズ可能な状態を保存する必要があるため、immer より外側に配置します。

typescriptCopy code// persist を immer より外側に配置
persist(
  immer(
    // immer の draft ではなく、
    // 実際の状態オブジェクトを保存
    (set) => ({
      /* ... */
    })
  ),
  { name: 'storage-key' }
);

immer の内側に persist を置くと、draft オブジェクトが保存対象となり、正しくシリアライズできません。

レイヤー 3：immer（3 層目）

immer は、状態更新の記法を改善するミドルウェアであり、subscribeWithSelector より外側に配置します。

typescriptCopy code// immer を subscribeWithSelector より外側に
immer(
  subscribeWithSelector((set) => ({
    data: { items: [] },
    addItem: (item) =>
      set((state) => {
        // immer により直接的な更新が可能
        state.data.items.push(item);
      }),
  }))
);

この配置により、set 関数内で immer の恩恵を受けながら、セレクターによる購読も利用できます。

レイヤー 4：subscribeWithSelector（最内層）

subscribeWithSelector は、ストアの基本的な購読機能を提供するため、最内層に配置します。

typescriptCopy code// subscribeWithSelector を最内層に
subscribeWithSelector((set) => ({
  // ここがコアのストア定義
  state: {},
  actions: {},
}));

この位置に置くことで、他の全てのミドルウェアがセレクター購読の機能を利用できるようになるのです。

合成順序を決定する思考プロセス

ミドルウェアを追加する際は、以下の質問を自問自答すると良いでしょう。

mermaidCopy codeflowchart TD
  start["新しいミドルウェアを<br/>追加したい"] --> q1{"全ての変更を<br/>監視する必要がある？"}
  q1 -->|はい| pos1["最外層に配置<br/>（logger/devtools）"]
  q1 -->|いいえ| q2{"シリアライズや<br/>永続化を行う？"}

  q2 -->|はい| pos2["外側寄りに配置<br/>（persist）"]
  q2 -->|いいえ| q3{"状態の更新方法を<br/>変更する？"}

  q3 -->|はい| pos3["中間層に配置<br/>（immer）"]
  q3 -->|いいえ| q4{"購読機能を<br/>提供する？"}

  q4 -->|はい| pos4["最内層に配置<br/>（subscribeWithSelector）"]
  q4 -->|いいえ| pos5["既存パターンと<br/>照らし合わせて判断"]

図で理解できる要点：

• ミドルウェアの役割から配置位置を決定
• 外側は監視系、内側は基盤系という原則
• 迷った場合は公式ドキュメントを参照

このフローチャートに従えば、新しいミドルウェアを追加する際にも、適切な位置を判断できるはずです。

具体例

パターン 1：全ミドルウェアを使用した完全な実装

実際のアプリケーションで使用できる、包括的な実装例をご紹介します。

型定義の準備

まず、TypeScript で型安全性を確保するための型定義を行います。

typescriptCopy codeimport { create } from 'zustand';
import {
  devtools,
  persist,
  subscribeWithSelector,
} from 'zustand/middleware';
import { immer } from 'zustand/middleware/immer';

必要なミドルウェアを全てインポートします。

typescriptCopy code// ストアの状態を表す型定義
interface Todo {
  id: string;
  text: string;
  completed: boolean;
}

interface StoreState {
  todos: Todo[];
  filter: 'all' | 'active' | 'completed';
}

まず、アプリケーションで扱うデータ構造を定義します。ここでは、Todo アプリの状態を例にしています。

typescriptCopy code// ストアのアクションを表す型定義
interface StoreActions {
  addTodo: (text: string) => void;
  toggleTodo: (id: string) => void;
  removeTodo: (id: string) => void;
  setFilter: (filter: StoreState['filter']) => void;
  clearCompleted: () => void;
}

type Store = StoreState & StoreActions;

状態とアクションを組み合わせて、完全なストアの型を作成します。

ストアの作成

型定義ができたら、実際のストアを作成しましょう。

typescriptCopy code// ✅ 推奨される順序での実装
export const useTodoStore = create<Store>()(
  devtools(
    persist(
      immer(
        subscribeWithSelector((set) => ({
          // 初期状態
          todos: [],
          filter: 'all',

          // アクション定義は次のブロックへ続く
        }))
      ),
      {
        name: 'todo-storage',
        partialize: (state) => ({ todos: state.todos }),
      }
    ),
    { name: 'TodoStore' }
  )
);

ミドルウェアを推奨順序で適用し、persist の設定で永続化する項目を指定しています。

アクションの実装

続いて、状態を変更するアクションを実装します。

typescriptCopy code// 前のブロックからの続き
export const useTodoStore = create<Store>()(
  devtools(
    persist(
      immer(
        subscribeWithSelector((set) => ({
          todos: [],
          filter: 'all',

          // Todo を追加
          addTodo: (text: string) =>
            set((state) => {
              state.todos.push({
                id: Date.now().toString(),
                text,
                completed: false,
              });
            }),

          // 次のブロックへ続く
        }))
      ),
      {
        name: 'todo-storage',
        partialize: (state) => ({ todos: state.todos }),
      }
    ),
    { name: 'TodoStore' }
  )
);

immer のおかげで、配列への push を直接書くことができます。不変性は自動的に保証されるのです。

typescriptCopy code// アクションの実装（続き）
// ストア定義内に以下を追加
toggleTodo: (id: string) => set((state) => {
  const todo = state.todos.find((t) => t.id === id)
  if (todo) {
    todo.completed = !todo.completed
  }
}),

removeTodo: (id: string) => set((state) => {
  state.todos = state.todos.filter((t) => t.id !== id)
}),

immer により、ネストしたオブジェクトのプロパティも直接変更できます。

typescriptCopy code// フィルターとクリーンアップ
setFilter: (filter) => set((state) => {
  state.filter = filter
}),

clearCompleted: () => set((state) => {
  state.todos = state.todos.filter((t) => !t.completed)
}),

これで全てのアクションの実装が完了しました。

コンポーネントでの使用

作成したストアを React コンポーネントで使用する方法を見てみましょう。

typescriptCopy codeimport { useTodoStore } from './store';
import { useEffect } from 'react';

typescriptCopy code// セレクターを使った効率的な購読
function TodoList() {
  // filter の変更のみを購読
  const filter = useTodoStore((state) => state.filter);

  // todos の変更のみを購読
  const todos = useTodoStore((state) => state.todos);

  const toggleTodo = useTodoStore(
    (state) => state.toggleTodo
  );
  const removeTodo = useTodoStore(
    (state) => state.removeTodo
  );

  // 表示用のフィルタリング
  const filteredTodos = todos.filter((todo) => {
    if (filter === 'active') return !todo.completed;
    if (filter === 'completed') return todo.completed;
    return true;
  });

  // JSX は省略
}

subscribeWithSelector により、必要な状態の変更だけを購読できるため、無駄な再レンダリングを防げます。

typescriptCopy code// subscribe を使った外部での購読
function setupSubscription() {
  // 特定の値の変更を監視
  const unsubscribe = useTodoStore.subscribe(
    (state) => state.todos.length,
    (todosLength, prevTodosLength) => {
      console.log(
        `Todos count changed: ${prevTodosLength} -> ${todosLength}`
      );
    }
  );

  return unsubscribe;
}

subscribeWithSelector のおかげで、コンポーネント外でも特定の値の変更を監視できるようになります。

パターン 2：persist と immer のみの組み合わせ

シンプルなアプリケーションでは、必要最小限のミドルウェアのみを使用することもあります。

typescriptCopy codeimport { create } from 'zustand';
import { persist } from 'zustand/middleware';
import { immer } from 'zustand/middleware/immer';

typescriptCopy codeinterface UserSettings {
  theme: 'light' | 'dark';
  language: 'ja' | 'en';
  notifications: {
    email: boolean;
    push: boolean;
  };
}

interface SettingsStore extends UserSettings {
  setTheme: (theme: UserSettings['theme']) => void;
  setLanguage: (language: UserSettings['language']) => void;
  toggleEmailNotification: () => void;
  togglePushNotification: () => void;
}

設定情報を管理するストアの型を定義します。

typescriptCopy code// ✅ persist と immer の組み合わせ
export const useSettingsStore = create<SettingsStore>()(
  persist(
    immer((set) => ({
      theme: 'light',
      language: 'ja',
      notifications: {
        email: true,
        push: false,
      },

      setTheme: (theme) =>
        set((state) => {
          state.theme = theme;
        }),

      setLanguage: (language) =>
        set((state) => {
          state.language = language;
        }),

      // 次のブロックへ続く
    })),
    { name: 'user-settings' }
  )
);

persist が外側、immer が内側という順序を守ります。

typescriptCopy code// アクションの実装（続き）
toggleEmailNotification: () => set((state) => {
  state.notifications.email = !state.notifications.email
}),

togglePushNotification: () => set((state) => {
  state.notifications.push = !state.notifications.push
}),

ネストしたオブジェクトも immer により簡単に更新できますね。

パターン 3：開発環境のみ logger を適用

本番環境ではログ出力を無効化し、開発環境でのみ有効にする実装方法です。

typescriptCopy codeimport { create } from 'zustand';
import { devtools, persist } from 'zustand/middleware';
import { immer } from 'zustand/middleware/immer';

typescriptCopy code// 条件付きでミドルウェアを適用するヘルパー
const conditionalDevtools = <T>(config: T) => {
  return process.env.NODE_ENV === 'development'
    ? devtools(config, { name: 'AppStore' })
    : config;
};

環境変数に基づいて、devtools の適用を切り替えるヘルパー関数を作成します。

typescriptCopy codeinterface AppState {
  count: number;
  increment: () => void;
  decrement: () => void;
  reset: () => void;
}

// ✅ 環境に応じた適用
export const useAppStore = create<AppState>()(
  conditionalDevtools(
    persist(
      immer((set) => ({
        count: 0,
        increment: () =>
          set((state) => {
            state.count += 1;
          }),
        decrement: () =>
          set((state) => {
            state.count -= 1;
          }),
        reset: () =>
          set((state) => {
            state.count = 0;
          }),
      })),
      { name: 'app-counter' }
    )
  )
);

この実装により、本番環境では devtools のオーバーヘッドを排除できます。

パターン 4：カスタムミドルウェアとの組み合わせ

独自のミドルウェアを作成し、既存のものと組み合わせる例をご紹介します。

typescriptCopy codeimport {
  StateCreator,
  StoreMutatorIdentifier,
} from 'zustand';

typescriptCopy code// カスタムミドルウェア：状態変更の履歴を記録
type HistoryMiddleware = <
  T extends object,
  Mps extends [StoreMutatorIdentifier, unknown][] = [],
  Mcs extends [StoreMutatorIdentifier, unknown][] = []
>(
  config: StateCreator<T, Mps, Mcs>
) => StateCreator<T, Mps, Mcs>;

const history: HistoryMiddleware =
  (config) => (set, get, api) => {
    const historyStack: any[] = [];

    return config(
      (args) => {
        historyStack.push(get());
        if (historyStack.length > 10) historyStack.shift();
        set(args);
      },
      get,
      api
    );
  };

このカスタムミドルウェアは、過去 10 件の状態を保持します。

typescriptCopy code// カスタムミドルウェアを既存のものと組み合わせる
interface CounterState {
  count: number;
  increment: () => void;
  undo: () => void;
}

typescriptCopy code// ✅ カスタムミドルウェアの配置
export const useCounterStore = create<CounterState>()(
  devtools(
    persist(
      history(
        // カスタムミドルウェア
        immer((set) => ({
          count: 0,
          increment: () =>
            set((state) => {
              state.count += 1;
            }),
          undo: () => {
            // 履歴から復元する処理
          },
        }))
      ),
      { name: 'counter-with-history' }
    )
  )
);

カスタムミドルウェアは、その役割に応じて適切な位置に配置します。この例では、immer の外側に配置しています。

よくあるエラーとその解決方法

実装時に遭遇しやすいエラーと、その対処法をまとめました。

エラー 1：Error: [immer] An immer producer returned a new value

このエラーは、immer の使い方を誤った際に発生します。

typescriptCopy code// ❌ エラーが発生する例
const useStore = create(
  immer((set) => ({
    count: 0,
    increment: () =>
      set((state) => {
        return { count: state.count + 1 }; // ❌ return で新しいオブジェクトを返している
      }),
  }))
);

typescriptCopy code// ✅ 正しい実装
const useStore = create(
  immer((set) => ({
    count: 0,
    increment: () =>
      set((state) => {
        state.count += 1; // ✅ state を直接変更する
      }),
  }))
);

immer 内では、state を直接変更するか、何も return しないようにします。

エラー 2：TypeScript の型エラー Type instantiation is excessively deep

ミドルウェアを多数重ねると、TypeScript の型推論が深くなりすぎてエラーになる場合があります。

typescriptCopy code// ✅ 型アサーションで解決
export const useStore = create<Store>()(
  devtools(
    persist(
      immer(
        subscribeWithSelector((set) => ({
          // ...
        }))
      ),
      { name: 'storage' }
    )
  )
) as typeof create<Store>;

型アサーションを使うことで、型推論の深さを制限できます。

エラー 3：persist による復元時の型不一致

永続化された古いデータ構造が、現在の型定義と一致しない場合に発生します。

typescriptCopy codeimport { PersistOptions } from 'zustand/middleware';

typescriptCopy code// ✅ migrate オプションで対応
const persistConfig: PersistOptions<Store> = {
  name: 'app-storage',
  version: 1,
  migrate: (persistedState: any, version: number) => {
    // バージョンアップ時のマイグレーション処理
    if (version === 0) {
      return {
        ...persistedState,
        newField: 'default-value',
      };
    }
    return persistedState;
  },
};

typescriptCopy codeexport const useStore = create<Store>()(
  persist(
    immer((set) => ({
      // ...
    })),
    persistConfig
  )
);

migrate オプションを使うことで、データ構造の変更に柔軟に対応できるようになります。

まとめ

Zustand のミドルウェア合成は、正しい順序を理解すれば決して難しくありません。

この記事でご紹介した基本原則をまとめますと、以下のようになります。

合成順序の基本原則

1. logger / devtools は最外層：全ての状態変更を監視するため
2. persist は immer より外側：シリアライズ可能な状態を保存するため
3. immer は subscribeWithSelector より外側：更新記法を改善するため
4. subscribeWithSelector は最内層：購読機能の基盤となるため

推奨される標準パターン

最も一般的な組み合わせは、次の通りです。

typescriptCopy codecreate(
  devtools(
    persist(
      immer(
        subscribeWithSelector()
        // ストア定義
      )
    )
  )
);

この順序を基本として、必要なミドルウェアのみを選択して使用すると良いでしょう。

実装時のチェックリスト

ミドルウェアを実装する際は、以下のポイントを確認してくださいね。

• ミドルウェアの役割を理解していますか
• 合成順序が推奨パターンに沿っていますか
• TypeScript の型エラーが出ていませんか
• 永続化する項目を適切に選択していますか
• 開発環境と本番環境で適切に切り替えていますか

これらを確認することで、安定したストア実装が実現できるはずです。

ミドルウェアの合成は、一度理解してしまえば、どのようなプロジェクトでも再利用できる知識となります。この記事が、皆さまの Zustand 開発をより快適にする一助となれば幸いです。

関連リンク

• Zustand 公式ドキュメント
• Zustand Middleware 公式ガイド
• Immer.js 公式ドキュメント
• TypeScript Deep Dive - Zustand
• GitHub - zustand repository