宣言的UIの状態管理とアーキテクチャ - SwiftUIとGraphQLによる実践 by そな太

SwiftUIではViewが状態を持たなくなることによりシンプルにコードでUIを表現できるようになりました。
しかし状態がなくなったわけではありません。この状態をどう管理していくかが問題になります。

宣言的UIコミュニティでは、状態管理手法について数年さまざまな議論を経て変化を遂げてきました。
その中で一定の答えが出ようとしています。その歴史と現在の回答を説明したいと思います。

本発表でみなさんがシンプルでスケーラブルなコードにより高速にiOSアプリを開発できる体制を構築するお手伝いができたらと考えています。

この発表では、以下について解説します。

• なぜ状態管理のアーキテクチャを考える必要があるのか？
• 宣言的UIの状態管理アーキテクチャの歴史(Flux、Redux、GraphQL)
  • Fluxが提案された根本的な理由と現代における異なる解決手段
  • Redux(The Composable Architecture)のボイラーテンプレートと正規化の課題
• コンポーネントとカプセル化
  • 状態とは何か？
  • 2つのSingle Source of Truth
  • Lifting State Up(State Hoisting)
  • Reducerの必要性
  • 状態の種別と管理方法、状態における新たな認識と捉え方
• 宣言的UI(SwiftUI)と宣言的データフェッチング(GraphQL)によるシンプルなアーキテクチャの実現
  • なぜAPI仕様であるはずのGraphQLが状態管理に関係するのか、クライアントキャッシュ
  • GraphQLとViewModel
  • Fragment Colocationによるスケーラブルな開発
  • RESTのためのクライアントキャッシュ