Recoil脱却の現状と挑戦

2025年7月24日の発表資料
https://offers-jp.connpass.com/event/360216/

Transcript

1. Recoil脱却の現状と挑戦 2025/7/24 株式会社PR TIMES 桐澤 康平 (@kiririLee)
2. 桐澤 康平 (@kiririLee) 株式会社PR TIMES 第二開発部 フロントエンドエンジニア 自己紹介 プレスリリース入稿画面のリニューアル、 メディアユーザー向けページのReactリプレイス などに従事
3. 行動者発の情報が、人の心を揺さぶる時代へ ・主力事業にプレスリリース配信サービス「PR TIMES」 ・「Jooto」、「Tayori」など行動者の支援を軸に多角的な 　事業を展開 タスク・プロジェクト管理ツール 「Jooto」 カスタマーサポートツール 「Tayori」 会社紹介
4. ・ Recoil剥がしの進捗と現状 ・ 新規プロジェクトでの状態管理 ・ 今後の運用 今日話すこと
5. Recoil剥がしの進捗と現状
6. 2024年12月の発表内容 https://speakerdeck.com/kirik/recoilwobo-gasiteiruhua
7. 2024年12月の発表内容 ・ React19バージョンアップに向けてRecoilを剥がしている ・ 移行先は useState, Context ・ Recoilの依存範囲の大きさを3つに分けてそれぞれ移行
8. 影響範囲別に３つに分けて進行中 ・影響範囲小： 　Recoilに依存しているファイル数が10ファイル以下のプロジェクト ・影響範囲中： 　20ファイル以下のプロジェクト ・影響範囲大： 　依存が特に広い50 〜 100ファイル以上のプロジェクト 進行方法
9. ・影響範囲小 　9つのプロジェクトの内7プロジェクト完了 ・影響範囲中 　3つのプロジェクトの内、現状どれもまだ手付かず ・影響範囲大 　4つのプロジェクトの内、2つのプロジェクトで派生状態に 　つらみを覚えながら進行中。 2024年12月時点の進捗
10. ・影響範囲小 完了！ ・影響範囲中 完了！ 　 ・影響範囲大 　4つのプロジェクトの内、残り１つ、、、！ 2025年7月時点の進捗
11. 標準APIのみで置き換えられているのか？
12. 結論だけ言うとNo 󰢁 影響範囲小: useState, Contextのみで移行完了 影響範囲中: useState, Context, TanStack Queryで完了 　 影響範囲大: 　4つのプロジェクトの内、3つが以下の技術で完了、、、！ 　useState, Context, TanStack Query, Jotai で完了
13. 標準APIのみを使う理想は捨てたのか？ No 󰢁 理想は変わらないが置き換えにおいてプロジェクトごとの コンポーネント設計が大きく影響する 主目的は設計の変更ではなくRecoilからの脱却 移行コストを減らすために他ライブラリを採用 新規プロジェクトでは標準APIのみを使う方針
14. 標準APIでの移行が困難なプロジェクト
15. エディタープロジェクト プレスリリースの本文に加え、配信先やタグ、キーワードなど 配信設定を編集できる
16. 各Stateが複雑に絡み合っ ており移行が困難 主要機能の大部分の情報が これらStateに載っている 本文・タイトル・タグ・キーワード・ メールタイトル・画像・メディア向 け情報・配信時刻などなど... https://developers.prtimes.jp/2025/07/18/compan y-page-recoil-migration/#index_id1 グラフの生成方法についてはブログをご覧ください
17. さらに、移行を困難にしている要因 ・ 更新ロジックがコンポーネントに露出 ・ 任意の場所から任意の状態に対して更新可能 　どこから何を更新しているのかコードから読み取りにくく、 Stateの用途が明確ではなくなっている この状況が変更を加えにくくしている
18. グラフが巨大になっている要因 APIで取得する データに主要機能で 扱うデータの大部分が 紐付いている Selector, atomFamilyなどで 分配 バックエンドに保存する 際はSelectorで集約
19. 主要機能の分配と集約の様子
20. useState と Context への移行 複雑に絡み合っている状態を標準APIで表現しようとすると 大幅なコンポーネント設計の見直しが必要... 工数的に修正を小さくしてQA範囲を狭めたリリースを 繰り返したいため、機能ごとに移行する方法を検討 しかし、仕様を保ったまま移行することが困難、 機能が多いためリリース回数も膨れ上がる 段階的な移行が難しく断念
21. エディターのRecoil脱却においてJotaiを採用 ・ Recoilと同じatomベースでAPIが似ており 　より少ない工数で移行できそう ・ 他プロジェクトでJotaiにより工数を削減して 　移行が完了した実績がある ・ 移行作業は進行中 エディターではReduxやZustandのような中央集権的なStoreベー スの状態管理がマッチしそう （移行予定はないです） エディターの性質から振り返り
22. 他プロジェクトでJotaiへの移行事例があるため 詳しくは以下のブログをご覧ください！ https://developers.prtimes.jp/2025/07/18/company-page-recoil-migration/
23. 新規プロジェクトでは標準APIのみで 開発できているか？
24. Yes ✅ 前提として、 ・ 非同期処理は TanStack Query ・ 基本的に useState のみを使用 ・ 一部 Context により useState を配布
25. メディアリスト機能の事例 https://prtimes.jp/main/html/rd/p/000001477.000000112.html
26. 1万800件超の配信先リストから最大300のメディアを 選択して配信リストを作る機能
27. ・ 標準APIのみを使う方針にしてから作成されたプロジェクト ・ 作成したリストの絞り込みや一時保存などで バックエンドとの同期が必要 ・ 数千件のリスト（配列）を扱う必要がある
28. バックエンドとの同期 上位コンポーネントで検索条件を管理しつつ愚直にpropsで 状態を配布 レイアウト
 useStateで 検索条件を管理 レイアウトレベル ナビゲーションの検索
 検索結果の表示
 検索処理
 検索条件を変更 TanStack Queryで データ取得 queryKeyによる 検索条件に応じたデータ反映 https://developers.prtimes.jp/2025/07/08/renewal-auto-media-list/#index_id5 ローディング画面の表示
 選択中のリスト表示

29. Render Props パターンによる階層を浅くする工夫
30. TanStack Virtual によるリストのパフォーマンス改善 現状、数千件のリストを扱う必要があり、動作が重くなる 事象が確認されていた 仕様として扱う件数に上限を定めていないため今後増える 可能性が高い 改善の必要性 TanStack Virtual 巨大なリストを仮想化するヘッドレスUIユーティリティ https://developers.prtimes.jp/2024/12/11/improving-performance-with-tanstack-virtual/
31. TanStack Virtual によるリストのパフォーマンス改善 パフォーマンス問題は他ライブラリへ委託 とはいえ今回のリストの問題はJotaiやZsutandでも同じことが言える ポイント パフォーマンスに限らず、非同期処理やブラウザAPIとの同期など ライブラリの責務を分担する もちろん同一のライブラリで複数の責務を統合した方が良い場合もある
32. メディアリストの状態管理で使っているツール リストデータの取得は TanStack Query リストの描画は TanStack Virtual ドロワーの開閉、フィルタリング、リストの選択状態など 要所要所の状態は useState 確認モーダルやトーストなど広い範囲で利用される コンポーネントは useState を Context で配布
33. 今後やっていきたい運用
34. Recoil脱却と理想を踏まえて ・ 新規プロジェクトでの基本方針 ・ ライブラリ導入時の方針 2つの観点でドキュメントの整備
35. 新規プロジェクトでの基本方針 前提として標準APIのみで開発を行うことの明示 　長期的な開発のために基本的には標準APIを使うことを前提とし 　安易なライブラリ導入を防ぐ 標準APIによる状態管理のプラクティスの共有 　可能な限り標準APIで実装をしていく際のTipsをまとめる
36. ライブラリ導入時の方針 ライブラリの責務を明確にする 　なぜライブラリを導入するのか？ライブラリで何を解決したいのか？ 変更容易性を保つ 　どのように導入するのか？ 　状態の設計をする、ラップする層を作ってテストを書く、 　利用するメソッドの制限による責務の制限など Design Doc や ADR に以下の観点を含める