Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Recoil脱却の現状と挑戦
Search
kirik
July 23, 2025
Technology
3
530
Recoil脱却の現状と挑戦
2025年7月24日の発表資料
https://offers-jp.connpass.com/event/360216/
kirik
July 23, 2025
Tweet
Share
More Decks by kirik
See All by kirik
Tiptapで実現する堅牢で柔軟なエディター開発
kirik
1
250
Recoilを剥がしている話
kirik
5
11k
Other Decks in Technology
See All in Technology
Oracle Exadata Database Service on Cloud@Customer X11M (ExaDB-C@C) サービス概要
oracle4engineer
PRO
2
6.4k
Findy Freelance 利用シーン別AI活用例
ness
0
670
Google Cloud で学ぶデータエンジニアリング入門 2025年版 #GoogleCloudNext / 20250805
kazaneya
PRO
24
5.9k
ユーザー課題を愛し抜く――AI時代のPdM価値
kakehashi
PRO
1
130
オブザーバビリティ文化を組織に浸透させるには / install observability culture
mackerelio
0
150
生成AIによるデータサイエンスの変革
taka_aki
0
3k
LTに影響を受けてテンプレリポジトリを作った話
hol1kgmg
0
380
Claude Codeは仕様駆動の夢を見ない
gotalab555
23
7k
Amazon GuardDuty での脅威検出:脅威検出の実例から学ぶ
kintotechdev
0
120
Lambda management with ecspresso and Terraform
ijin
2
170
リリース2ヶ月で収益化した話
kent_code3
1
310
Nx × AI によるモノレポ活用 〜コードジェネレーター編〜
puku0x
0
760
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
140
7.1k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
How STYLIGHT went responsive
nonsquared
100
5.7k
The Invisible Side of Design
smashingmag
301
51k
Speed Design
sergeychernyshev
32
1.1k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.8k
YesSQL, Process and Tooling at Scale
rocio
173
14k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Writing Fast Ruby
sferik
628
62k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Cost Of JavaScript in 2023
addyosmani
53
8.8k
Transcript
Recoil脱却の現状と挑戦 2025/7/24 株式会社PR TIMES 桐澤 康平 (@kiririLee)
桐澤 康平 (@kiririLee) 株式会社PR TIMES 第二開発部 フロントエンドエンジニア 自己紹介 プレスリリース入稿画面のリニューアル、 メディアユーザー向けページのReactリプレイス
などに従事
行動者発の情報が、人の心を揺さぶる時代へ ・主力事業にプレスリリース配信サービス「PR TIMES」 ・「Jooto」、「Tayori」など行動者の支援を軸に多角的な 事業を展開 タスク・プロジェクト管理ツール 「Jooto」 カスタマーサポートツール 「Tayori」 会社紹介
・ Recoil剥がしの進捗と現状 ・ 新規プロジェクトでの状態管理 ・ 今後の運用 今日話すこと
Recoil剥がしの進捗と現状
2024年12月の発表内容 https://speakerdeck.com/kirik/recoilwobo-gasiteiruhua
2024年12月の発表内容 ・ React19バージョンアップに向けてRecoilを剥がしている ・ 移行先は useState, Context ・ Recoilの依存範囲の大きさを3つに分けてそれぞれ移行
影響範囲別に3つに分けて進行中 ・影響範囲小: Recoilに依存しているファイル数が10ファイル以下のプロジェクト ・影響範囲中: 20ファイル以下のプロジェクト ・影響範囲大: 依存が特に広い50 〜 100ファイル以上のプロジェクト 進行方法
・影響範囲小 9つのプロジェクトの内7プロジェクト完了 ・影響範囲中 3つのプロジェクトの内、現状どれもまだ手付かず ・影響範囲大 4つのプロジェクトの内、2つのプロジェクトで派生状態に つらみを覚えながら進行中。 2024年12月時点の進捗
・影響範囲小 完了! ・影響範囲中 完了! ・影響範囲大 4つのプロジェクトの内、残り1つ、、、! 2025年7月時点の進捗
標準APIのみで置き換えられているのか?
結論だけ言うとNo 影響範囲小: useState, Contextのみで移行完了 影響範囲中: useState, Context, TanStack Queryで完了
影響範囲大: 4つのプロジェクトの内、3つが以下の技術で完了、、、! useState, Context, TanStack Query, Jotai で完了
標準APIのみを使う理想は捨てたのか? No 理想は変わらないが置き換えにおいてプロジェクトごとの コンポーネント設計が大きく影響する 主目的は設計の変更ではなくRecoilからの脱却 移行コストを減らすために他ライブラリを採用 新規プロジェクトでは標準APIのみを使う方針
標準APIでの移行が困難なプロジェクト
エディタープロジェクト プレスリリースの本文に加え、配信先やタグ、キーワードなど 配信設定を編集できる
各Stateが複雑に絡み合っ ており移行が困難 主要機能の大部分の情報が これらStateに載っている 本文・タイトル・タグ・キーワード・ メールタイトル・画像・メディア向 け情報・配信時刻などなど... https://developers.prtimes.jp/2025/07/18/compan y-page-recoil-migration/#index_id1 グラフの生成方法についてはブログをご覧ください
さらに、移行を困難にしている要因 ・ 更新ロジックがコンポーネントに露出 ・ 任意の場所から任意の状態に対して更新可能 どこから何を更新しているのかコードから読み取りにくく、 Stateの用途が明確ではなくなっている この状況が変更を加えにくくしている
グラフが巨大になっている要因 APIで取得する データに主要機能で 扱うデータの大部分が 紐付いている Selector, atomFamilyなどで 分配 バックエンドに保存する 際はSelectorで集約
主要機能の分配と集約の様子
useState と Context への移行 複雑に絡み合っている状態を標準APIで表現しようとすると 大幅なコンポーネント設計の見直しが必要... 工数的に修正を小さくしてQA範囲を狭めたリリースを 繰り返したいため、機能ごとに移行する方法を検討 しかし、仕様を保ったまま移行することが困難、 機能が多いためリリース回数も膨れ上がる
段階的な移行が難しく断念
エディターのRecoil脱却においてJotaiを採用 ・ Recoilと同じatomベースでAPIが似ており より少ない工数で移行できそう ・ 他プロジェクトでJotaiにより工数を削減して 移行が完了した実績がある ・ 移行作業は進行中 エディターではReduxやZustandのような中央集権的なStoreベー
スの状態管理がマッチしそう (移行予定はないです) エディターの性質から振り返り
他プロジェクトでJotaiへの移行事例があるため 詳しくは以下のブログをご覧ください! https://developers.prtimes.jp/2025/07/18/company-page-recoil-migration/
新規プロジェクトでは標準APIのみで 開発できているか?
Yes ✅ 前提として、 ・ 非同期処理は TanStack Query ・ 基本的に useState
のみを使用 ・ 一部 Context により useState を配布
メディアリスト機能の事例 https://prtimes.jp/main/html/rd/p/000001477.000000112.html
1万800件超の配信先リストから最大300のメディアを 選択して配信リストを作る機能
・ 標準APIのみを使う方針にしてから作成されたプロジェクト ・ 作成したリストの絞り込みや一時保存などで バックエンドとの同期が必要 ・ 数千件のリスト(配列)を扱う必要がある
バックエンドとの同期 上位コンポーネントで検索条件を管理しつつ愚直にpropsで 状態を配布 レイアウト useStateで 検索条件を管理 レイアウトレベル ナビゲーションの検索 検索結果の表示 検索処理
検索条件を変更 TanStack Queryで データ取得 queryKeyによる 検索条件に応じたデータ反映 https://developers.prtimes.jp/2025/07/08/renewal-auto-media-list/#index_id5 ローディング画面の表示 選択中のリスト表示
Render Props パターンによる階層を浅くする工夫
TanStack Virtual によるリストのパフォーマンス改善 現状、数千件のリストを扱う必要があり、動作が重くなる 事象が確認されていた 仕様として扱う件数に上限を定めていないため今後増える 可能性が高い 改善の必要性 TanStack Virtual
巨大なリストを仮想化するヘッドレスUIユーティリティ https://developers.prtimes.jp/2024/12/11/improving-performance-with-tanstack-virtual/
TanStack Virtual によるリストのパフォーマンス改善 パフォーマンス問題は他ライブラリへ委託 とはいえ今回のリストの問題はJotaiやZsutandでも同じことが言える ポイント パフォーマンスに限らず、非同期処理やブラウザAPIとの同期など ライブラリの責務を分担する もちろん同一のライブラリで複数の責務を統合した方が良い場合もある
メディアリストの状態管理で使っているツール リストデータの取得は TanStack Query リストの描画は TanStack Virtual ドロワーの開閉、フィルタリング、リストの選択状態など 要所要所の状態は useState
確認モーダルやトーストなど広い範囲で利用される コンポーネントは useState を Context で配布
今後やっていきたい運用
Recoil脱却と理想を踏まえて ・ 新規プロジェクトでの基本方針 ・ ライブラリ導入時の方針 2つの観点でドキュメントの整備
新規プロジェクトでの基本方針 前提として標準APIのみで開発を行うことの明示 長期的な開発のために基本的には標準APIを使うことを前提とし 安易なライブラリ導入を防ぐ 標準APIによる状態管理のプラクティスの共有 可能な限り標準APIで実装をしていく際のTipsをまとめる
ライブラリ導入時の方針 ライブラリの責務を明確にする なぜライブラリを導入するのか?ライブラリで何を解決したいのか? 変更容易性を保つ どのように導入するのか? 状態の設計をする、ラップする層を作ってテストを書く、 利用するメソッドの制限による責務の制限など Design Doc や
ADR に以下の観点を含める