Jotai、Zustand、Contextの比較：使い分け

React Contextは、現在のテーマ、ユーザーのロケール、認証状態、デザインシステムのトークンなど、変更頻度の低いグローバル値に適しています。これらの値は一度設定されると、セッション中に変更されることはほとんどありません。

APIがReactに組み込まれていて依存関係が不要なうえ、「この値はグローバルに共有される」という意図をチームに明確に伝えられます。

contextの値オブジェクトが変更されると、1つのフィールドだけの変更であっても、すべてのコンシューマーが再レンダリングされます。安定したグローバル設定には問題ありませんが、フォーム入力やUIアニメーションのフラグのように高頻度で変化する状態では致命的です。

contextを小さく分割すれば影響を部分的に緩和できますが、大規模になると扱いにくいパターンになります。

Zustandは、ユーザー設定、ショッピングカート、ナビゲーション履歴、複数ステップのウィザード状態など、中程度の頻度で変化するグローバルなアプリケーション状態に適しています。セレクターによる購読により、関係のない状態スライスによる再レンダリングを防ぎます。

ストアベースのモデルはReduxユーザーにもなじみやすく、関連する状態を1か所に集約できます。

ZustandのストアはuseBoundStoreフックをエクスポートします。セレクターを渡します：useStore(state => state.cart)。これによりcartスライスだけを購読できます。異なるセレクターを使用するコンポーネントは互いに独立しているため、cartセレクターを使うコンポーネントはユーザー名が変更されても再レンダリングされません。

これにより、ZustandはJotaiと同様のスライス単位の効率性を、より命令型のAPIで実現します。

Jotaiは、多数の小さく独立した値が頻繁に変化する細粒度のリアクティブな状態に適しています。たとえば、個々のフォームフィールドの値、行ごとの選択フラグ、UIのトグル状態、リアルタイムデータの購読などです。

atomを値ごとに持つモデルにより、コンポーネントツリーの異なる部分でまったく異なる状態スライスが必要な場合にも自然に扱えます。

Jotaiのバンドルは、Zustandより小さくなっています。Jotaiは機能が少なく、ミドルウェアシステムや組み込みのdevtoolsがないためです。JotaiのAPIはuseStateによく似ており、useAtom returns [value, setter]という形式なので、React開発者の学習コストを抑えられます。

ZustandのAPIはよりReduxに近く、ストアを定義し、フックをエクスポートして、セレクターを使用します。どちらのライブラリもTypeScriptを優れたレベルでサポートしています。

JotaiとZustandはどちらも、適切なハイドレーション戦略によってサーバーサイドレンダリングをサポートします。JotaiではSSRにProviderとカスタムストアを使用し、ZustandではサーバーインスタンスにcreateStoreを使用します。

どちらもTypeScriptのジェネリクスを第一級でサポートしているため、手動で型注釈を付けなくても、atomとstoreの値に対する完全な型推論が得られます。

実際のアプリでは、3つすべてを組み合わせることがよくあります。静的な設定（APIのベースURL、機能フラグ）にはReact Context、インタラクティブなクライアント状態にはJotaiまたはZustand、サーバーから取得するデータにはReact QueryまたはSWRを使用します。

これらのレイヤーは競合しません。各状態スライスの性質に基づいて意図的に組み合わせることは、アーキテクチャ上のベストプラクティスです。

チームにReduxの経験がある場合は、Zustandのストアモデルを自然に感じられます。チームがReact-nativeに深く慣れている場合は、JotaiのuseStateに似たAPIが最も学びやすい選択肢です。

ほとんどのアプリケーションでは、わずかなパフォーマンス差よりも、チームの慣れのほうが重要です。

いくつかのトグルだけを持つ単純なページ状態であれば、useStateまたはContextで十分です。中規模アプリでコンポーネント間の状態を扱うなら、ZustandまたはJotaiを使います。数十個の独立したリアクティブな値を持つ非常にインタラクティブなUIでは、Jotaiが力を発揮します。

キャッシュ、バックグラウンド更新、楽観的更新を伴う複雑なサーバー状態には、任意のクライアント状態管理ライブラリとReact Queryを組み合わせます。

静的なグローバル値や、ほとんど変更されないグローバル値にはContextを使います。更新頻度が中程度の、集中管理するアプリケーション状態にはZustandを使います。多数の独立した購読がある、きめ細かなアトム単位のリアクティブ状態にはJotaiを使います。サーバー状態にはReact QueryまたはSWRを使います。

これらの分類は相互排他的ではありません。状態の種類に応じて組み合わせることで、整理され、パフォーマンスの高いアーキテクチャになります。

React Contextは静的なグローバル設定に、Zustandはセレクターに基づく購読を備えた集中管理型のアプリケーション状態に、Jotaiは多くの独立した値が頻繁に更新されるきめ細かなアトミック状態に適しています。3つとも、React Queryのようなサーバー状態ライブラリを補完します。

更新頻度、状態の複雑さ、チームの慣れを基準に選びます。状態の種類ごとに3つすべてを使い分ける構成は、有効で一般的な本番環境のパターンです。