Reduxモダナイズ 〜コードのモダン化を通して、将来のライブラリ移行に備える〜

2025-09-21 フロントエンドカンファレンス東京 2025

Reduxモダナイズ　〜コードのモダン化を通して、将来のライブラリ移行に備える〜

https://fec-tokyo.github.io/2025/
https://fec-tokyo.connpass.com/event/352581

Transcript

1. Reduxモダナイズ 〜コードのモダン化を通して、将来のライブラリ移行に備える〜 フロントエンドカンファレンス東京 2025 pvcresin
2. pvcresin 仕事　Sansan で Eight の Webエンジニア 業務　DX向上 / デザインシステム / Rubyの型 趣味　アニメ / お笑い / 謎解き / デザイン展 自己紹介
3. 本セッションについて 話すこと - Reduxの基本コンセプトと段階的なモダン化 - 他のライブラリへの移行を視野に入れた工夫 想定する参加者 - 古のReduxと格闘している方 - 他の状態管理ライブラリの経験があり、Reduxを学びたい方
4. 1. Reduxについて 2. Redux Toolkitによるモダナイズ 3. 将来のライブラリ移行を見据えた実装 4. まとめ アジェンダ
5. Reduxについて
6. 2015年に発表された状態管理ライブラリ State of React 2024: State Management - 77%がReduxの使用経験がある - 肯定的な割合は Zustand → Jotai → Redux Toolkit 基本コンセプト - 状態を1つの箱（Store） にまとめる - 変更は必ず Action → Reducer を通して行う Redux
7. Reduxの概要 Action イベントを表すオブジェクト Viewからdispatchされる Store 状態を内包する単一の箱 Reducer Actionを受け取って 状態を更新する関数 State グローバルな状態 View Component Component Component Component
8. Reduxのデータフロー 状態を表示する コンポーネント群 View Reducer Store Action 状態を内包する単一の箱 イベントを表すオブジェクト Viewからdispatchされる Actionを受け取って 状態を更新する関数
9. View Reducer Store Action イベントを表すオブジェクト Viewからdispatchされる Actionを受け取って 状態を更新する関数 状態を内包する単一の箱 状態を表示する コンポーネント群
10. - Actionを生成するためのAction Creator関数 - Stateは複数の子Stateで構成され、対応するReducerが存在 実際はもう少し複雑 Store .profile: { } .users: { } .posts: { } State Profile Reducer Reducer Users Reducer Posts Reducer
11. - 状態を一元管理 →　Single Source of Truthの実現 - 一方向データフロー →　データの流れが明確で予測しやすい - Reducerが純粋関数 →　ユニットテスト・変更の追跡が容易 Reduxの特徴と利点
12. Redux DevTools https://chromewebstore.google.com/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd
13. - 登場人物（用語）が多い - ボイラープレートとなるコードが多い Reduxの課題
14. Redux Toolkitによるモダナイズ
15. 公式Docで推奨されている、Reduxをより簡単に扱うためのツール 特徴 - シンプルな記述によるボイラープレートの削減 - 段階的移行が可能 - 型と相性が良い Redux Toolkit（RTK）
16. Immer - Proxyを使うことで、ImmutableなStateをMutableライクに更新できる Redux Thunk - Actionに関数を渡せるようにして、API呼び出し等の非同期処理を実現 Reselect - Stateの値を取り出す際にセレクタをメモ化し、無駄な再計算を防ぐ RTKに含まれるライブラリ
17. 状態管理のモダン化
18. 1. ActionTypeの定数化とcreateActionの導入 2. createReducerの導入 3. createSliceの導入 状態管理のモダン化
19. 題材: シンプルな Counter
20. 不要なReducerが残る可能性 ActionTypeの定数化と createActionの導入 Actionの削除に連動、Actionの標準化
21. payloadの型が不安 createReducerの導入 Actionの型を再利用、mutableな操作
22. - Action CreatorとReducerをひとまとめにしたような概念 - Reducerの処理を書くと、Action Creatorも自動的に作られる Slice
23. ReducerからAction Creatorを生成 Action CreatorとReducerを別に管理 createSliceの導入
24. データ取得のモダン化
25. 1. createAsyncThunk 2. RTK Query データ取得のモダン化
26. - Actionに関数を渡せるようにして、API呼び出し等の非同期処理を実現 - Actionの中で別のActionを呼び出すことが可能 Redux Thunk
27. 題材: 人名取得・表示
28. 多くのActionを作成する必要がある createAsyncThunkの導入 一度にまとめてActionを定義できる
29. RTKに組み込まれている、データ取得・キャッシュ用ライブラリ 特徴 - Hooksベースのデータ取得・更新 - 内部的にRedux Thunkでデータを取得を扱い、Sliceに格納 - 同一クエリはキャッシュを利用 RTK Query
30. ActionとReducerの管理が必要 RTK Query（createApi）の導入 Hooksベースで手軽にデータ取得
31. モダン化のまとめ 状態管理 - ActionとReducerの紐づけを強め、Sliceに統合 データ取得 - Actionの管理をやめ、使用するAPIの定義を一元化することで HooksベースのRTK Queryに移行
32. 将来のライブラリ移行を見据えた実装
33. 状態管理系 - Zustand、Jotai、Valtio、(Recoil) データ取得系 - SWR、TanStack Query、Apollo、urql Reduxからの移行先の一例
34. - インターフェースが異なる - ライブラリから直接importしている - 動作が異なる 移行するに当たって困るポイント
35. インターフェースの違いを見る
36. 値と更新関数をHooksから提供、dispatchがない ZustandとReduxを見比べる
37. - Custom Hookで整理して隠蔽 - Custom Hookを別ファイルに切り出すことで、中間層を形成 Zustandに寄せていく
38. - ライブラリを直接importしないように設ける層 - 他のライブラリにインタフェースを揃えやすくなる - ライブラリへの依存をコントロールできる - さらに移行を楽にするなら、より深いAPIを既存ライブラリで再現する 中間層
39. Hooksにkey情報とfetcherを渡す形式 → SWRをRTK Queryに寄せる SWRとRTK Query
40. 動作の確認
41. 2つのライブラリを同時に動かしてみる
42. - インターフェースが異なる →　末端から寄せる - ライブラリから直接importしている →　中間層を設ける - 動作が異なる →　両方動かす 移行するに当たって困るポイント
43. まとめ
44. - Reduxは段階的にモダン化できる - モダン化によってボイラープレートが削減され、依存が整理される - モダンなコードはライブラリの移行にも有用 - インタフェースが異なる場合も、中間層を設けることでスムーズに進む まとめ