Storeで扱う状態のライフサイクル

Transcript

1. Storeで扱う状態の ライフサイクル React.js meetup #8 2019/7/29 @as_masa
2. ⾃⼰紹介 • 浅沼 昌幸 (Masayuki Asanuma) • Twitter : @as_masa • Fringe81株式会社 • 広告プロダクト系エンジニア • React, TypeScript, Elm, Scala • 今年からReact始めました
3. Hooks流⾏っていますが、今回は FluxアプリケーションのStoreの話です
4. Storeってどうしていますか︖
5. Storeの実現⽅法 • Fluxのまま • Single source of truthにしたいからReduxにしてる
6. この辺使ってStoreを実現すると 状態管理の悩み出ませんか︖
7. 状態管理の悩み • 1Store=1モデル vs 1Store=複数モデルどっち︖ • Storeが肥⼤化する • ローカルステート保持は、コンポーネント vs Storeどっち︖ • モデルの整合性はどう担保するの︖
8. モデルの整合性はどう担保するの︖の詳細 • Storeにデータ上関連したモデルA、Bを保持している • インタラクションが発⽣して、モデルAが型が同じでデータ が違うモデルA’になった。 • データ上関連がなくなったモデルBは古い状態のまま保持し て良いの︖適切な更新忘れると、バグに繋がりそう。 4UPSF Ϟσϧ" Ϟσϧ# 関連あり 4UPSF Ϟσϧ"b Ϟσϧ# 関連なし インタラクション発⽣
9. この悩みを解決するために アプリケーション特性に則した ライフサイクルを考えませんか︖
10. アプリケーション特性 僕が考えるアプリケーション特性は2つ ໊শ ಛ௃ શ෦ࡌͤܥ ɾϖʔδભҠ͕ൃੜ͠ͳ͍ ɾ5XJUUFS΍'BDFCPPLͷΑ͏ͳλΠϜϥΠϯ ܥ΋͜͜ ϖʔδભҠܥ ɾϖʔδભҠ͕ൃੜ͢Δ ɾ؅ཧαΠτ΍&$αΠτ౳
11. 全部載せ系のライフサイクル • アプリケーション起動から終了までで考える • 全ての状態は終了するまでなくならない • 学びたてや、意識しないと⾃然に作っちゃってるパ ターンになります • タイムライン系は、モデルの状態を捨てること があまりなく、差分を追加する傾向があるので こちらにカテゴライズ
12. ページ遷移系のライフサイクル 2つのライフサイクルが登場する • 全部載せ系と同様に、アプリケーション起動から終了までのライフサイクル • アプリケーション状態と呼ぶことにする • ほぼ変動しない状態(ログイン情報とか、マスターデータ的な)を持つ • ページ表⽰から別ページに遷移するまでのライフサイクル • ページ状態と呼ぶことにする • ページに必要な状態を持つ 4UPSF ΞϓϦέʔγϣϯ ঢ়ଶ 5PQϖʔδ ঢ়ଶ 4UPSF ΞϓϦέʔγϣϯ ঢ়ଶ Ϣʔβ ϖʔδঢ়ଶ ページ遷移 4UPSF ΞϓϦέʔγϣϯ ঢ়ଶ Ϩϙʔτ ϖʔδঢ়ଶ ページ遷移
13. ライフサイクルのGood ページ遷移系のメリットが主となります。。。 • ライフサイクルを型で定義できる • 例: Topページ型とか、Userページ型とか • ページ遷移ごとにライフサイクルオブジェクト を変えるので、管理しやすい
14. Storeを擬似コードで表現してみる 4UPSF ΞϓϦέʔγϣϯ ঢ়ଶ 5PQϖʔδ ঢ়ଶ 4UPSF ΞϓϦέʔγϣϯ ঢ়ଶ Ϣʔβ ϖʔδঢ়ଶ ページ遷移 4UPSF ΞϓϦέʔγϣϯ ঢ়ଶ Ϩϙʔτ ϖʔδঢ়ଶ ページ遷移 class ApplicationData { user: string; } const applicationData = new ApplicationData(); class TopPage {} // Store { applicationData: applicationData, page: new TopPage() }; class User {} class UserPage { users: User[]; } // Store { applicationData: applicationData, page: new UserPage() }; class Report {} class ReportPage { reports: Report[]; } // Store { applicationData: applicationData, page: new ReportPage() };
15. ライフサイクルのBad • 全部載せ系 • メモリ使いすぎる可能性あり • ページ遷移系 • 遷移毎に外部から状態を取得し直すので、遅くなる
16. 状態管理の悩みへの回答1 • 1Store=1モデル vs 1Store=複数モデルどっち︖ • ライフサイクルで纏められるので、Fluxのみでも 1Store=複数モデルにしたい • Storeが肥⼤化する • ライフサイクルを考える • ライフサイクルに沿って、必要な状態を保持する ようになっていれば問題なし • ライフサイクル外の状態を持っていれば⻩⾊信号
17. 状態管理の悩みへの回答2 • ローカルステート保持は、コンポーネント vs Storeどっち︖ • 同じライフサイクルで管理したいので、お気持ち的 にはStore • モデルの整合性はどう担保するの︖ • アプリケーション特性に則したライフサイクルで強 制する
18. まとめ • Storeを設計する時には、保持する状態のライフ サイクルを考える • アプリケーション特性によってライフサイクル が決めれる
19. TODO • アプリケーション特性って他にもないのか考え る • ページ単位の他に機能単位の切り⼝もありえそうな 気がしてきている • まだソース検証していないので実践が必要 • 全部載せ系、名前がダサいの変えたい
20. ご清聴 ありがとうございました︕