状態管理は、Next.js で構築されたアプリケーションを含む、堅牢な React アプリケーションの開発に不可欠な部分です。 Zustand と Jotai は、状態を管理するためのさまざまなアプローチを提供する 2 つの人気のある状態管理ライブラリです。この記事では、Next.js アプリケーションで Zustand と Jotai を使用するための最良の状況と最悪の状況を探り、その使用法を示すコード サンプルも示します。

ズスタンド

概要

Zustand は、React 用の小型、高速、スケーラブルな状態管理ライブラリです。シンプルな API を提供し、そのパフォーマンスと使いやすさで知られています。

Zustandを使用するのに最適な状況

1. 単純な状態管理のニーズ:

• シナリオ: アプリケーションが複雑なロジックを使用せずに、シンプルでグローバルな状態管理を必要とする場合。
• 例: モーダル、サイドバー、グローバル読み込み状態などの UI 状態を管理します。

// store.js  
import create from 'zustand';  

export const useStore = create((set) => ({  
  isModalOpen: false,  
  toggleModal: () => set((state) => ({ isModalOpen: !state.isModalOpen })),  
}));

// Modal.js  
import React from 'react';  
import { useStore } from '../store';  

const Modal = () => {  
  const { isModalOpen, toggleModal } = useStore();  
  return (  
    
  
      {isModalOpen && 
Modal Content
}  
      Toggle Modal  
    
  
  );  
};  

export default Modal;

2. 高パフォーマンス要件:

• シナリオ: パフォーマンスが重要であり、オーバーヘッドを最小限に抑えた状態管理ライブラリが必要な場合。
• 例: ライブ チャットやゲーム アプリなど、状態の更新に高いパフォーマンスが必要なリアルタイム アプリケーション。

3. 統合の容易さ:

• シナリオ: 重要な定型文なしで既存の React コンポーネントと簡単に統合できる状態管理ソリューションが必要な場合。
• 例: コードベースを再構築せずに、小規模から中規模のプロジェクトに状態管理を迅速に追加します。

4. サーバーサイド レンダリング (SSR):

• シナリオ: Next.js で SSR を使用する場合、クライアントとサーバーの両方で適切に動作する状態管理ライブラリが必要です。
• 例: SEO 上の利点や初期読み込み時間を短縮するために、初期状態をサーバー上でレンダリングする必要があるアプリケーション。

// pages/\_app.js  
import App from 'next/app';  
import { useStore } from '../store';  

const MyApp = ({ Component, pageProps }) => {  
  return ;  
};  

MyApp.getInitialProps = async (appContext) => {  
  const appProps = await App.getInitialProps(appContext);  
  const { isModalOpen } = useStore.getState();  
  return { ...appProps, initialZustandState: { isModalOpen } };  
};  

export default MyApp;

Zustandを使用するのに最悪の状況

1. 複雑な状態のロジック:

• シナリオ: アプリケーションに、ディープ ステート ツリーや複雑な関係など、非常に複雑な状態管理のニーズがある場合。
• 例: 多数の相互接続されたステートフル コンポーネントと複雑な状態遷移を備えた大規模なエンタープライズ アプリケーション。

2. 広範な派生状態:

• シナリオ: アプリケーションが派生状態に大きく依存しており、セレクターとメモ化の組み込みサポートが必要な場合。
• 例: Recoil や MobX を使用する場合と同様、状態に基づいて広範に計算されたプロパティを必要とするアプリケーション。

3. 非常に大規模なアプリケーション:

• シナリオ: アプリケーションが非常に大きく、状態管理に対して高度に構造化されたアプローチが必要な場合。
• 例: 複数のチームがさまざまなモジュールに取り組んでいるアプリケーションでは、より意見があり構造化された状態管理アプローチが有益である可能性があります。

常体：

概要

Jotai は、アトミックな状態に焦点を当てた、React 用の最小限の状態管理ライブラリです。これにより、アトムと呼ばれる小さな独立した部分で状態を管理できるようになります。

Jotaiを使用するのに最適な状況

1. 原子状態管理:

• シナリオ: アプリケーションが状態をきめ細かく制御できる利点があり、小さく独立した部分で状態を管理することを好む場合。
• 例: 各フィールドの状態が独立して管理される複雑なフォーム。

// atoms.js  
import { atom } from 'jotai';  

export const formFieldAtom = atom('');

// FormField.js  
import React from 'react';  
import { useAtom } from 'jotai';  
import { formFieldAtom } from '../atoms';  

const FormField = () => {  
  const \[value, setValue\] = useAtom(formFieldAtom);  
  return (  
     setValue(e.target.value)} />  
  );  
};  

export default FormField;

1. スコープ付き状態:

• シナリオ: アプリケーションの特定のコンポーネントまたはセクションに範囲を限定した状態を管理する必要がある場合。
• 例: 各セクションが独自の独立した状態を持つ複数ステップのウィザードまたはダッシュボード。

2. 動的状態の要件:

• シナリオ: 実行時に状態を動的に作成および管理する必要がある場合。
• 例: 状態の構造が事前に不明な動的フォームまたはデータ駆動型コンポーネント。

3. デバッグのしやすさ:

• シナリオ: アプリケーションの状態変化を簡単に追跡およびデバッグする必要がある場合。
• 例: 状態変化のフローを理解することが保守とデバッグに重要なアプリケーション。

Jotai を使用するのに最悪の状況

1. グローバル状態管理:

• シナリオ: アプリケーションで多くのグローバルな状態管理が必要で、より集中的なアプローチを好む場合。
• 例: 状態の大部分がグローバルであり、アプリケーションのさまざまな部分からアクセスおよび変更する必要があるアプリケーション。

2. 複雑なコンポーネント間通信:

• シナリオ: アプリケーションが異なるコンポーネント間の複雑な対話と通信を必要とする場合。
• 例: 相互の状態変化を頻繁に共有し、それに反応する必要がある多数のコンポーネントを含むアプリケーション。

3. パフォーマンスの最適化:

• シナリオ: パフォーマンスの最適化が重要であり、メモ化と派生状態用の組み込みツールが必要な場合。
• 例: 大量の計算が状態から派生し、効率的な再計算戦略が必要なアプリケーション。

4. サーバーサイド レンダリング (SSR):

• シナリオ: Jotai は SSR をサポートしていますが、他の状態管理ライブラリと比較してより多くのボイラープレートとセットアップが必要になる場合があります。
• 例: SSR セットアップを簡単かつ最小限にする必要があるアプリケーション。

結論

Zustand と Jotai はどちらも独自の利点を備えており、Next.js アプリケーションのさまざまなシナリオに適しています:

• 最小限のセットアップでシンプルで高性能な状態管理が必要で、主にグローバルな状態を処理する場合、またはスムーズな SSR 統合が必要な場合は、Zustand を使用してください。
• アトミックな状態管理を希望する場合、状態のきめ細かい制御が必要な場合、またはスコープ付きまたは動的な状態要件に対処している場合は、Jotai を使用します。