宣言的UIのモジュラリティや堅牢性はコンポーネント設計で担保する
#モジュール性 #宣言的UIの設計レシピ #堅牢
Atomic Designとはまた別の話
@koushisa: CSSもHTMLもステートもコンポーネント志向開発においてモジュラリティを担保するのはいつだってコンポーネント設計
@okunokentaro: Reactにて複数の案件でEmotion, Tailwind CSSの両方を採用して思ったけど、重要なのはそのどっちを使うかではなくて、コンポーネントをどの粒度で切るかなんだよな…。
---
システムの堅牢性とは
---
GUIでスケーラブルなアプリを書く秘訣は、良いコンポーネントを適切なタイミングで抽出することで、それ以上のことはない
宣言的UIの哲学
モジュラリティはコンポーネント設計で担保する
宣言的UIのデータアーキテクチャはコンポーネントを中心に考える
設計における最小単位は部材ではなくパタン
-> 宣言的UIの関心の最小単位はCSSでもJSでもHTMLでもなく、コンポーネント
コンポーネント = HTML x a11y x CSS x JSの相互作用をカプセル化したもの
React Docsにその哲学が詳細に書いてある
コンポーネントを中心に組み立てる
ステートのスコープを狭めて凝集度をとにかく高くすると自然とモジュール性も高くなっていく
Deep ModuleとShallow Moduleのトレードオフ
困難は分割せよ(サブドメイン分割)
そのコンポーネントの責務とは何か?他のコンポーネントとの境界線はなんなのかを強く意識する
データフロー
原則はLifting state upと単方向データフロー(unidirectional data flow)
状態変化の契機はユーザーの発するActionの単位にする
GUIの状態遷移の命名はイベントを冠したものにしたい
アプリケーションロジックの命名にCRUDを持ち込まない
ステート/オブジェクトのライフサイクルを追う時にコンポーネントツリーから追えるようにする
Elmの哲学
データとロジックは近い位置にまとめる
UIコンポーネントへドメインを持ち込まない
propsバケツリレーでも構わない
ステートの依存関係や責任範囲をわかりすることのほうが大事
冗長性 < 変更容易性
安易なReact > ContextやGlobal State, Atomic State Managementの利用は悪手
階層関係がおかしくなる
同じGlobal Stateをデータソースにしていると共通結合以上にするのが難しい
予期しない挙動の確率が高まる
リグレッション管理が大変
Pub/SubやuseEffectなどコンポーネント外の暗黙的な状態変化は最終手段
どうしても使いたいならコンポーネントの共通結合を外部結合に引き上げる
Recoil/Jotai使う前にトップダウン型の状態管理をアンラーニングすべし
言うのは簡単だが、その引き出しは体で慣れるしかない
#宣言的UIの設計レシピ