宣言的UI
https://gyazo.com/eb4a21791ad8b6a6d1024ad4d85790df
sonatard
ツールの目的を理解できないと適切な技術選択の困難
Declarative = 「宣言的」というキーワード
宣言的UIに価値を感じないから不採用はあり
細かい実装手段はあんまり気にしなくていい
Declarativeを採用しているもの
なぜ採用されたか
Reactの存在
宣言的UIを使うためにReactを使おう
しかし宣言的UIを意識している人は多いのかもしれない
VMのステートの管理
Reduxのアーキテクチャの議論が多かった
命令的
How
何をするか
宣言的
What
どうなっているかを記述する
HTML, CUIは宣言的
どのような状態を表示するかを記述する
一般的な動的GUI
Viewに何が入るかがわからない
イベントでViewが変化
前のViewの状態に依存
時間軸と何が起きているかを理解しないといけない
宣言的UIの過去の課題
GUIでもCUIと同じように状態更新ごとに再描画しなおすと宣言的にはなるが
現実的なコードではない
毎回再描画は遅い
宣言的にViewを表現する
状態管理の課題
保持する場所
宣言的とはいえあくまでも分離されただけ
方針
ローカルステート
コンポーネントが保持する
再利用性がある
全体の状態の把握が難しい
グローバルステート
single source of truth
Store
全体の状態の把握が容易
現在の状態の再現が容易
受け渡し方
状態を引数として受け取る
問題点
バケツリレーになり得る
グローバルからステートを渡す
Reduxだと connect, selector 一定の秩序を保つ必要がある
rootのみにconnectするなど
更新はできないのでグローバル変数ほど危険ではない
更新方法
下位から上位のものを参照・更新するとき
コールバックとして渡す
変数の参照をして更新
イベントを発行して更新
$emit
グローバルステートの更新
イベントを通知して更新
NewState = Event + OldState
Viewとの同期の方法
バインディングは単方向か双方向か？
フレームワークでサポートしているかを理解する
ロジックの再利用
HoC（High Order Component） 状態とロジックをコンポーネントが持たなければいけない
状態、ロジック、ライフサイクルを管理できる
凝集度は高いほうがいい（時間的凝集）
関数を切り出す（カスタムフック）
機能的凝縮
宣言的UIとアーキテクチャ
アーキテクチャが目指すところ
ドメインとそれ以外の責務を分割
View Model の状態管理
クリーンアーキテクチャやレイヤードアーキテクチャ
Presentation以外の責務の分離