フロントエンドの状態管理とMiiTelにおける事例の紹介

「Jotai? Zustand? そもそも不要？ 3社の運用事例から学ぶ 状態管理設計のイマ」イベントに関する発表資料です (https://offers-jp.connpass.com/event/360216/)

MiiTel PhoneにおけるRecoilからJotaiへの移行やその他のMiiTelにおけるプロダクトの事例などを元に、フロントエンドの状態管理や技術選定などについて紹介します。

Transcript

1. Copyright © RevComm Inc. フロントエンドの状態管理とMiiTelにおける事例の紹介
2. Copyright © RevComm Inc. 自己紹介 - Tanaka Yuki - 株式会社RevComm - MiiTel Phone の開発 - DevRel (社内TechTalkやTechBlogの運 営) - 趣味でdeno-weeklyというサイトを運営して います🦕
3. Copyright © RevComm Inc. コミュニケーションを再発明し 人が人を想う社会を創る
4. Copyright © RevComm Inc. 電話営業や顧客応対を自動録音、AIが文字 起こし、解析・可視化することにより、顧 客と担当者が「何を」「どのように」話し ているか分からない、というブラックボッ クス問題を解消し、商談獲得率・成約率の 向上やセルフコーチングを後押しします。 Service ビジネス向けスマート電話
5. Copyright © RevComm Inc. Culture フルリモート フルフレックス プロフェッショナル 自由と責任を 尊重する文化
6. Copyright © RevComm Inc. Language and tools 言語/ フレームワーク インフラ/運用管理 コミュニケーション
7. Copyright © RevComm Inc. www.revcomm.co.jp/careers/ エンジニアの皆様、ご興味がある方は 是非ご連絡ください。
8. Copyright © RevComm Inc. contents 1. はじめに 2. グローバルの状態管理について 3. MiiTel PhoneにおけるRecoilの移行事例について 4. MiiTelにおけるフロントエンド 5. まとめ - どのライブラリを採用するべきか？
9. Copyright © RevComm Inc. 1. はじめに Recoilのメンテナンスが停止 (2025/01)
10. Copyright © RevComm Inc. 1. はじめに ・RecoilはMiiTelにおいても広く使われており、メンテナンス 停止による影響は大きそうです ・今後、React v19へのアップデートなども控えており、別の 選択肢へ移行したいです
11. Copyright © RevComm Inc. 1. はじめに グローバル状態の管理に関する選択肢 ・Redux? ・Jotai? ・Zustand? ・TanStack Query? ・SWR? ・Context API?
12. Copyright © RevComm Inc. 1. はじめに グローバルな状態の管理のための選択肢はた くさん存在します。 どれを採用すべきでしょうか？
13. Copyright © RevComm Inc. 2. グローバル状態の管理について グローバル状態の管理手法に関する分類 ※ 1. Context API 2. ストア (Redux, Zustand, Mobx, など) 3. Atomic State Management (Recoil, Jotai) 4. Server State Management (TanStack Query, SWR, Apollo, RTK Query, など) ※ これはおおさっぱな分類のため、あくまで参考程度にとどめていただければと思います
14. Copyright © RevComm Inc. 2. グローバル状態の管理について 1. Context API
15. Copyright © RevComm Inc. 2. グローバル状態の管理について 1. Context API
16. Copyright © RevComm Inc. 2. グローバル状態の管理について 1. Context API
17. Copyright © RevComm Inc. 2. グローバル状態の管理について 1. Context API - メリット - React標準のAPIである (追加のライブラリの導入・管理が不要 ) - 手軽である - デメリット - 意図せぬパフォーマンス低下が起きうる (extra re-render issue) - 手軽に利用しやすい分、乱用してしまうリスクはありそうです - どこで採用すべき？ - 更新頻度が低い状態や読み込み専用の状態の共有、コンポーネントへ依存注入し たいケースなどで利用するのが良いと思います
18. Copyright © RevComm Inc. 2. グローバル状態の管理について 2. ストア (Redux, Zustand, MobXなど)
19. Copyright © RevComm Inc. 2. グローバル状態の管理について 2. ストア (Redux, Zustand, MobXなど)
20. Copyright © RevComm Inc. 2. グローバル状態の管理について 2. ストア - メリット - 堅牢 (状態がストア内にカプセル化されるため意図せぬ不整合を防止しやすい、 ReduxにおけるReducerは純粋関数であるため容易に独立してユニットテストが可 能) - Server State (後述) / Client Stateのどちらも管理が可能で、汎用性は高め - デメリット - 記述などは冗長にはなりがち - どこで採用すべき？ - 複雑な状態遷移のモデリングが必要なケースなど
21. Copyright © RevComm Inc. 2. グローバル状態の管理について 3. Atomic State Management
22. Copyright © RevComm Inc. 2. グローバル状態の管理について 3. Atomic State Management
23. Copyright © RevComm Inc. 2. グローバル状態の管理について 3. Atomic State Management
24. Copyright © RevComm Inc. 2. グローバル状態の管理について 3. Atomic State Management - メリット - 手軽・シンプル・柔軟で、汎用性も高い - レンダリングの最適化を提供 (atomの更新時に、それに依存したコンポーネントの みを再レンダリング) - デメリット - 手軽で柔軟、かつ汎用性も高いため、必要以上の乱用には注意が必要そうです - どこで採用すべき？ - ストアを採用するのはToo muchであり、Context APIの使用が適さないケース、な ど
25. Copyright © RevComm Inc. 2. グローバル状態の管理について 4. Server State Management
26. Copyright © RevComm Inc. 2. グローバル状態の管理について 4. Server State Management - メリット - Server Stateの管理に伴う複雑さを軽減してくれる - 目的がはっきりしていて使い方や使うべき場面を間違えにくい - デメリット - ストアやAtomic State Managementなどの汎用的手法と異なり、汎用的ではありま せん (用途に応じてそれらと併用すると良いでしょう ) - どこで採用すべき？ - REST APIやGraphQLなどによってサーバーとやり取りを行い かつ キャッシュ制御 やリトライなどを柔軟に実装・管理したい場合
27. Copyright © RevComm Inc. 3. MiiTel PhoneにおけるRecoilの移行事例について MiiTel Phoneにおける移行前の構成 - 状態管理としてはRecoil+Apolloを採用 - Server StateはApolloで管理し、それ以外の大部分を Recoilで管理 - 一部REST APIを使用している箇所があり、そのほとんどはアプリの起動時に一回だけ 読 み込んでおけば十分であるため、 TanStack Queryなどは使わずにRecoilで管理してい ます
28. Copyright © RevComm Inc. 3. MiiTel PhoneにおけるRecoilの移行事例 Recoilからの移行先の選択肢 1. Jotai 2. Redux 3. Context API
29. Copyright © RevComm Inc. 3. MiiTel PhoneにおけるRecoilの移行事例 結論: RecoilからJotaiに移行することにしました - 先ほどの分類においてRecoilと同じカテゴリーに属し、APIもよく似ているため、他の選択 肢と比較して移行コストの大幅な削減が期待できる - JotaiはすでにRevComm内の他のプロダクトにおいて採用事例があった (十分にワーク してくれることがすでに実証されている ) - Atomic State ManagementはMiiTel Phoneにおいてはほとんどのケースでうまく機能し てくれていた (Reduxへ移行する必要性は高くなかった ) - 移行における具体的な対応については RevCommのTechBlogで公開しています (MiiTel PhoneでRecoilからJotaiへの移行を行いました)
30. Copyright © RevComm Inc. 3. MiiTel PhoneにおけるRecoilの移行事例 選択しなかった理由 - Redux - MiiTel PhoneにおいてはRecoilで共有していた状態の多くは単純な更新処理で済 むものが大半であり、ReduxはややToo muchであること (一部、Reduxが欲しいと 思う箇所はあるものの、JotaiにはatomWithReducerなどのAPIもあるため、十分に 対応可能と判断) - Context API - パフォーマンスに関する懸念を考慮する必要があり、 Jotaiと比較して移行コストが かかってしまうと判断しました。また、 MiiTel Phoneにおいてはスムーズな通話体験 を提供したいため、パフォーマンス劣化は避けたいです。
31. Copyright © RevComm Inc. 3. MiiTel PhoneにおけるRecoilの移行事例 Jotaiはどうなの？ - 大抵のケースでうまくワークしてくれている印象 - 汎用性が高く柔軟であるため、選択肢が多くて何を採用したらいいかわからないと言うよ うな場合にとりあえず採用する選択肢としても悪くなさそうに思っています - 汎用性が高い分、乱用には注意した方が良さそうには感じています (useStateで十分な 場合はそれで済ませる)
32. Copyright © RevComm Inc. 4. MiiTelにおけるフロントエンド 傾向 全体的にRecoilやJotaiとServer State Management用のライブラリを併用しているプロダクト が多いです 背景 - MiiTelは機能や用途ごとに細かくサービスやプロダクトを分割して提供しているケースが 多いです - 全体的に軽量なソリューションが採用されることが多い
33. Copyright © RevComm Inc. 4. MiiTelにおけるフロントエンド MiiTel Phone - Jotai+Apolloの構成 - Server StateはApollo, それ以外をJotaiで管理 - 一部、複雑な状態管理が必要でストアによる管理が適している箇所もありますが、それは 少数であるため現状はJotaiで対応しています - 一部、REST APIによってサーバーと疎通している箇所がありますが、アプリの初回起動 時のみに読めば十分なリードオンリーなデータがほとんどであり、複雑な管理も不要であ るため、TanStack Queryなどは使わずにJotaiで管理しています
34. Copyright © RevComm Inc. 4. MiiTelにおけるフロントエンド MiiTel Analytics - 基本的にはJotai+TanStack Queryの組み合わせを採用 - MiiTel Phoneとは異なり、サーバーとの疎通はほぼ REST APIを経由しているため、 ApolloではなくTanStack Queryを採用 - 様々なチームのメンバーが開発に参加している関係でマイクロフロントエンド構成を採用 しており、一部のチームではContext APIへの移行を検討していたりもします
35. Copyright © RevComm Inc. 5. まとめ - どのライブラリを採用するべきか？ 個人的なおすすめ プロダクト・サービスの性質と各種状態管理ライブラリの特徴やメリット・デメリットを踏まえた上 で、適したものを採用するのがおすすめです
36. Copyright © RevComm Inc. 5. まとめ - どのライブラリを採用するべきか？ 判断がつかない場合 1. まずはバニラReact (useState) + Server State Management系のライブラリの組み合 わせで開発を進めるのが良いと思っています (最初から完璧な設計や判断を行うのは難 しいため、まずは小さく始める) 2. ある程度開発が進み、プロダクトに求められる要件や性質などが明らかになってきたら、 その段階でプロダクトに適したライブラリを導入すればミスマッチは減らせるはずです - 例) 堅牢さが求められる場合はストア (Redux, Zustandなど) を採用し、そうでなけ れば Jotai を導入する、など
37. Copyright © RevComm Inc. Thank you!