RecoilからJotaiへ移行すべき7つの理由と注意点！React状態管理最適化ガイド

この記事の最終更新日: 2025年5月20日

はじめに

React アプリの成長とともに、状態管理ライブラリを見直す機会は必ず訪れます。本記事では Recoil を採用しているプロジェクトが Jotai へ移行すべき理由と、移行時にハマりやすいポイントを解説します。両者の違いを押さえつつ、実際のコード例を交えながらステップバイ‑ステップで紹介するので、既存コードを抱えるチームでも安心して読み進められます。

対象読者: 既に Recoil を導入している React 開発者、状態管理の再検討を行っている技術選定担当者

Recoil と Jotai ── 共通点と決定的な違い

なぜ Jotai が注目されるのか?

1. 極小バンドルサイズ – Recoil の 1/4 以下。
2. BOILERPLATE の削減 – key が不要なため定義がシンプル。
3. 派生ロジックが関数だけ – selector を覚える必要がなく、学習コストが低い。
4. TypeScript との相性 – ジェネリクスと conditional type を活用し推論ミスが少ない。
5. RSC/Concurrent Mode への先行対応 – React のロードマップに追従。
6. 周辺エコシステム – jotai/query, jotai-trpc など公式プラグインが活発。
7. ミニマル設計 – Redux Toolkit との併用も容易で “ライブラリロックイン” がない。
8. コミュニティの勢い – GitHub ⭐ が加速中 (2025/04 時点で 19.9k ⭐)。

移行前に必ず確認したい 6 つのチェックリスト

1. アトムのリストアップ – key を含む全アトム/セレクターを洗い出す。
2. 非同期セレクターの有無 – Suspense を前提に書かれたロジックは atom(async (get) => …) へ置換する必要あり。
3. グローバルキャッシュ要件 – RecoilRoot に依存したキャッシュスコープを再設計。
4. DevTools 利用状況 – Recoil DevTools 相当の機能は jotai-devtools で補完。
5. サードパーティー依存 – recoil-persist などを使用している場合は atomWithStorage 系へ。
6. テストコード – Jotai では Provider をモックする必要がなくなる場合があるため修正箇所を把握。

コードで見る移行パターン

① 基本アトム

// Recoil
export const countAtom = atom({
  key: "count",
  default: 0,
});

// Jotai
export const countAtom = atom(0);

② 派生状態 (selector ➡ derived atom)

// Recoil
export const doubleCountSelector = selector({
  key: "doubleCount",
  get: ({ get }) => get(countAtom) * 2,
});

// Jotai
export const doubleCountAtom = atom((get) => get(countAtom) * 2);

③ 非同期セレクター

// Recoil
export const userAtom = selector({
  key: "user",
  get: async () => {
    const res = await fetch("/api/user");
    return res.json();
  },
});

// Jotai (Suspense)
export const userAtom = atom(async () => {
  const res = await fetch("/api/user");
  return res.json();
});

コードベースが大きい場合は jotai-recoil-bridge を使い、段階的に移行すると安全です。

ステップバイ・ステップ移行ガイド

1. 依存ライブラリを追加 pnpm add jotai jotai-devtools
2. RecoilRoot の隣に Provider を設置 (暫定共存) const App = () => ( <RecoilRoot> <Provider> <Router /> </Provider> </RecoilRoot> );
3. 単純なアトムから移行 – UI 影響が小さいものを優先して差し替え。
4. セレクターを derived atom へ移行 – 型安全を確認しながら進める。
5. 非同期ロジックを移行 – Suspense の依存度を再評価し、必要なら useSWR などとの連携を検討。
6. RecoilRoot の削除 – 全コンポーネントが Jotai に置き換わったらリムーブ。
7. Production Build を検証 – バンドルサイズ削減とパフォーマンス計測。

落とし穴と回避策

導入後のベストプラクティス

• アトムはドメインごとにディレクトリ分割し、index.ts で再エクスポート。
• 派生ロジックは必ずメモ化し、不要な再計算を防ぐ。
• React DevTools Profiler でレンダリング回数を可視化し、React.memo の適用を検討。
• ストレージ同期 が必要な場合は atomWithStorage を使い、Key を localStorage から疎結合に。
• Server Components を使う場合は jotai/vanilla に分離し、クライアントに渡す props を最小化。

まとめ

Jotai はミニマルで学習コストが低いにもかかわらず、Concurrent/Server Components に最適化された次世代型の状態管理ライブラリです。Recoil を採用した中規模以上のプロダクトでも、段階的に移行することでバンドルサイズ削減とメンテナンス性向上を同時に実現できます。

次のアクション: まずは小さなアトムを一つだけ Jotai へ置き換え、開発体験とパフォーマンスの変化を測ってみましょう。

2025年4月最新版ライブラリ動向

Jotai v2.12.3 (2025-04-14)

• 内部 API を整理し jotai-devtools 依存機能を切り出し。
• React 19 の use API と Server Actions を試験的にサポート（utils/atomWithObservable など）。
• 新しい suspense 制御フラグでプリミティブな Promise ステータスを付与。

Recoil の状況

• 2025-01-01 をもって GitHub リポジトリがアーカイブされ、read‑only となりました。
• 最終リリースは v0.7.7 (2023‑04‑11)。React 18 向けのバグフィックスが最後で、今後パッチは提供されません。

エコシステム拡充

• jotai-tanstack-query が 0.8.0‑beta で TanStack Query v5 に追随。
• jotai-trpc 0.7.1 (2025‑01‑25) で onData サブスクリプションに正式対応。
• SSR/Lazy Hydration を支援する @suspensive/jotai v3 系が公開され、Next.js App Router + RSC に最適化。

採用トレンド

• NPM 週次ダウンロード数: Recoil 約 0.5 M ➡ Jotai 1.4 M+。
• DEV Community や Medium の事例記事では「Recoil から Jotai へ移行してレンダリングが 30–40 % 改善」との報告が増加。

上記の変更点は本記事全体の比較表・移行ガイドに反映済みです。

参考リンク

• Jotai Official Docs
• Recoil → Jotai Migration Recipes
• jotai-devtools

daigoro

大阪のエンジニアが書いているブログ。