Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

reduxのstate設計の話

https://connpass.com/event/113502/

  • Be the first to comment

reduxのstate設計の話

  1. 1. Reduxのstate設計の話 2019/1/29 スタートアップテック
  2. 2. 自己紹介  名前:澤木綾太(@ayatas0623)  所属:OPEN8 Inc.  技術:フロントエンドメインで、React, redux, Vue, Type Scriptとか いろいろ触ってます。最近はfirebase興味あります。
  3. 3. VIDEO BRAIN  AIを利用した動画編集ツール  React + redux の SPAで構成
  4. 4. Reduxのstate設計
  5. 5. Redux  クライアントサイドでの状態管理のためのライブラリ  状態は一箇所で管理される(Single source of truth)
  6. 6. ReduxのState設計  状態は一箇所で管理される(Single source of truth) Stateは一つのツリーとして管理される
  7. 7. 設計方針  stateは一つのツリーとして管理される -> ツリーをどのように切っていくか?  stateの切り方  画面ベースの設計  ドメインベースの設計
  8. 8. 画面ベースの設計
  9. 9. 画面ごとにstateを分ける  原則として一画面に対して対応するstateを一つ作成するような設 計  ページコンポーネントのstateをそのままreduxへ吐き出すイメージ page pageState
  10. 10. メリット  画面のコンポーネントと1対1で対応するので分け方について悩 むことが少ない
  11. 11. デメリット  画面数分stateを分ける必要があるため画面数が多くなってきた場 合に辛い  ビューの変更に弱い
  12. 12. ドメインベースの設計
  13. 13. ドメインごとにstateを分ける  画面には依存せずドメインベースでstateを分けていく設計  UserやSessionなどドメインごとにstateを切っていく page domainState1 domainState2 domainState3
  14. 14. メリット  stateが画面に依存しない形になるので、ビューの変更に強い  データ箇所が一つにまとまるのでロジックなどの共通化がやりや すい
  15. 15. デメリット ビューごとのの個別のstateなどを扱うのが難しい
  16. 16. 実際どのような設計にしたか
  17. 17. 全体の構成 /entities …APIからフェッチしてきたデータを正規化して保持 /各ドメインのstate /lists …各ドメインのリストデータを保持 /edits …各ドメインの編集データを保持 /ui …グローバルなUIの表示状態を保持
  18. 18. /entities APIからフェッチしてきたデータを正規化して一箇所で管理 各ドメインのstateからはidでこちらのデータを参照する形に する
  19. 19. 正規化 APIからのデータをidをキーとするオブジェクトに変換する { id: 1, title: "project1", scenes: [ { id: 1, name: "scene1", }, { id: 2, name: "scene2" } ] } entities: { projects: { 1: { id: 1, title: "project1", scenes: [1, 2] } }, scenes: { 1: { id: 1, name: "scene1" }, 2: { id: 2, name: "scene2" } } }
  20. 20. 正規化のメリット オブジェクトの構造がフラットになるため変更を加えやすい データが一箇所にまとめられるためentitiesを変更することで 全ての場所に変更を反映することができる
  21. 21. /各ドメインのstate 編集データを/edits、リストのデータを/listsとしてstateを分 けて管理 それぞれのstateではkeyをつけて個別のデータを管理
  22. 22. 各stateの構造 /lists lists: { [key]: { ids: [1, 2, 3], loading: false } } /edits edits: { [id]: { name: hugahuga, ... } }
  23. 23. /ui グローバルで状態管理したいモーダルなどの表示状態を保持 ビューごとの状態はなるだけcomponentに持たせるように
  24. 24. まとめ フェッチしてきたデータは正規化して一箇所に保存 各ドメインからはidで参照 UIデータは別で管理、なるべくコンポーネントに寄せる
  25. 25. 課題 ビュー側の処理とドメイン側の共通処理の切り分け reducerの肥大化
  26. 26. おわり

×