UIコンポーネントへドメインを持ち込まない
#宣言的UIの設計レシピ #コンポーネントツリー
UIコンポーネントにドメインを入れるな
ReactのPresentationalコンポーネントに渡す関数は on から始めたい
UIに依存した部分は極力文脈を持たない世界で完結させ、文脈を持つ世界では用意されたUIを使うことに徹することで、それぞれの責務に集中できる
ViewModelのメソッド名はイベントを表す命名にしたいという話
今回の例だと、 save ではなく onSaveButtonClick のような命名に変更できれば、Viewの責務は ViewModelへイベントを伝搬すること のみであるということを明確にすることができ、バリデーションのロジックも自然とViewModelの onSaveButtonClick 内で書く流れが生まれやすいと思います。
関心の分離はドメインとプレゼンテーションから考える(PDS), Container/Presenterパターン
UIコンポーネントのイベントハンドラは結果がどうなるかは関心を持たない
振る舞いは上位階層で決める
<PresentationalComponent onXXX={handleXXX}/>
処理の詳細はonXXX: ()=> voidに任せる
GUIの状態遷移の命名はイベントを冠したものにしたい
「それがなにか」(What)と「どうするか」(How)の分離
副作用は最初と最後に寄せる
UIコンポーネントはピュアであるべき(=UIコンポーネントを副作用で挟む)
UIがピュアだと振る舞いが変更しやすく改修時に腐りづらい
イベント発行からのレスポンスを期待しないことと、レスポンスからの状態更新をしないことが、物事をシンプルに保つ
機能は追加よりも変更したり削除するほうが難しい
振る舞いのバリエーションが増えた際に、「変更」ではなく「追加」で対応できることを目指す
ロジックを扱う場合は、常にバリエーションが増えるか？を問いかける
物がそこにあってそれに接する者との間に意味空間が立ち上がる
UIオブジェクト達は動くように動くだけで、個別状況には無頓着
振る舞いは物が置かれる環境によって決まる
UIコンポーネントは親コンポーネントの文脈によりどう振る舞うかが決まる
UIコンポーネントが特定の文脈に依存したpropsや具体的すぎる命名のイベントハンドラを扱うということは、文脈に依存しているということ
UIに依存した部分は極力文脈を持たない世界で完結させ、文脈を持つ世界では用意されたUIを使うことに徹することで、それぞれの責務に集中できる
共通化と抽象化
optionalな引数を増やさない
- 責務が肥大化していく
- local reasoningとかは例外
ifで分岐しない
- パターンを用意して呼び出し側で切り替える