#設計 #状態管理

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

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

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

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

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

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

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

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

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

個人的な趣向やノウハウ

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

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

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

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

→Atomic State Management

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

データフロー

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