状態管理(GUI)

#設計 #状態管理

「状態管理」って何？

なぜ状態管理が必要なのか

ReadModelを木構造ではなくグラフ構造にしたい

状態管理を構成する 3 つの要素とそれらが解決したい状態管理の課題

「それがなにか」(What)と「どうするか」(How)の分離

仕組み

バグは正常に動いている2つの機能の狭間に発生する

GUIの状態管理は線形では表せない

State-Action-Model (SAM)パターン

StateとStatusの使い分け

React Docs

Thinking about UI declaratively

https://react.dev/learn/sharing-state-between-components

https://react.dev/learn/managing-state

原則

歴史

GUIのデータアーキテクチャと状態管理の変遷

理論的に最大限堅牢な実装を示したもの (関連: 何事も全体の構造から捉える)

Redux

The Composable Architecture

koushisa.icon

変数や要件の不確実性の多い状況で完璧な管理を目指すのは不毛

複雑な状態管理が必要なのは実は少数の機能だけだったりする

そのシステムのコア機能となりうるもの

顧客にとっての絶対的な価値を持つ機能

複雑なドメインを備えているのはごく一握りの画面だけだった

問題をゼロにすることを目標にしていない、制御できてるならそれでいい

ソフトウェア式年遷宮

コードスニペットはインターネットに溢れているのに対しコードベースはすべてユニーク

状態を作り出すUI/UXと密結合でプロダクトごとに固有

フレームワークとしての状態管理はかなり難しくカーゴカルトプログラミングになりがち

特定の状態管理手法を全体方針としてルール化すると経験上は制約や運用難のデメリットのほうが大きく付く

一番複雑な画面を表現可能な構成で全体をカバーしようとしてもメンタルモデルが一致しない

属人性は低い方がよいが、属"技能"性はそうではない

ベストプラクティスのワーストなところ

ベスト/グッドプラクティスよりもアンチパターンを優先的に理解する

ボトルネックとなりうる箇所を重点的に考える

複雑性保存の法則

制約理論(TOC)

個人的な趣向やノウハウ

https://www.notion.so/koushisa/c70a3c6196224ece8995cf8dda33d6b7?pvs=4

コツや関心の分離のまとめ

フロントエンドのステートの分類

ミニマムにインクリメンタルに作っていきたい

Worse is Better

無駄を削ぎ落とすことはステークホルダ全方位にメリットしかない

コンポーネントを中心に、まずはuseState, useReducerで考える

useState vs useReducer

コロケーション

宣言的UIのモジュラリティや堅牢性はコンポーネント設計で担保する

宣言的UIのデータアーキテクチャはコンポーネントを中心に考える

UIコンポーネントへドメインを持ち込まない

本質的にフロントエンドの複雑性が高くてステートフルに作らざるを得ない場合にModule Level Stateを導入する

→Atomic State Management

Form StateとServer Stateは最初からAtomic State Managementにリフトアップする

Async Selector: APIは「叩く」のではなく「叩かれる」もの

データフロー

イベントハンドラ(Action)からの単方向データフロー(unidirectional data flow)

ドメインをデータのワークフローと捉えるのか、ユーザーが期待する振る舞いと捉えるか

「それがなにか」(What)と「どうするか」(How)の分離