宣言的UIの振る舞いを分割する単位はページなのか機能なのか

宣言的UIのデータモデルとその振る舞いをどういう単位で分割していくか？

Reduxが主流だった時代はReducerをページ単位で管理しているケースが多く見受けられたが、React Hooks登場以降は機能単位で管理するのが主流だと感じている

これはkoushisa.iconの経験上でも当てはまる

UXを重視するほどページという単位での設計は責務が肥大化して破綻しやすい

機能ごとに固有のステートやロジックを露出させたくない

Atomic Designの言葉を借りると、organismsの中で更に機能単位でコンポーネント切る

organisms = ドメインのネームスペース的な

code:tsx

export const CustomersPage = () => <CustomersTemplate/>

export const CustomersTemplate = () => <CustomersRoot/>

// 顧客検索画面のorganisms的な

export const CustomersRoot = () => {

return (

// 顧客検索(フィルタとか)

// 顧客一覧(テーブル)

</>

)

}

機能固有のステートはなるべくコンポーネントのローカルステートに押し込めるイメージ

機能をまたいだステートが必要なときはRootの中でローカルステートを使いつつ各コンポーネントのpropsに流し込む

2022/11

コンポーネントをまたぐステート管理はLifting state up (ここでいうとRootにリフトアップする)

機能(organisms | パッケージ)間やステートの依存関係が木構造ではない場合はAtomic State Management or イベント駆動

機能間の結合を避けたいときや仕様変更の不確実性がかなり高い時だけ使う

GA, Sentryみたいな通知系もろもろを機能本体と疎結合にしたいとか

イベント駆動のためのReduxはややオーバーと感じる

機能間で共通する処理は共通化と抽象化に留意した上で適切に移譲すればok

最近はあまり共通化を考えずにパッケージごとに独立させるモジュラモノリス的な思考かも