状態管理ではなく関係と関連に着目した状態法則を考える
可能な限り状態を廃する関数型プログラミングやReactの哲学で重要な考え方
動的に解決する部分を減らして、静的に解決出来る部分を増やす
一種の制約プログラミングなのかもしれない？
特定の時間軸の状態を引数としてUIを形成する空間「コンポーネント）を抽象化した
コンポーネントごとに固有の時間軸と空間のスコープを扱える
Clojureでは状態に対するアイデンティティを持つ、と表現するらしい
状態にアイデンティティを与えることでUIの時空を分割統治できるようになった
React HooksとImmutable Modelと関数型コンポーネント
クラス型のUIはミュータブルである
インスタンス変数を持つとレンダリングに利用される状態とインスタンス変数の値が一致しないケースがある
クラスはミュータブルであるため
Reactの関数型コンポーネントはImmutable Modelである
レンダリングと状態のスナップショットは一位になる
状態が変化したら配下の空間はすべてて作り直される
関数型コンポーネントを利用していると状態の時間軸と空間は一致する
useEffectを使っていない限りは状態はレンダリングと一位になる
宣言型プログラミングのパラダイムを持つため、殆どの変数は式で表現できる
言い換えるとUIがとりうる状態を法則として表せる
状態法則
この式を一般化したものにモナドがある
コアとなるデータに対して利用者ごとにあればいいなと思うデータ表現を考える
与えられたデータ表現をそのまま扱わない
センテンスは関数にする
tsx1. data = (serverState * clientState) // クライアントとサーバーの状態をかけあわせる式
2. UI = Component(data) // 純粋なレンダリング処理この
1. data の式の組み合わせにより状態を算出する参照透過性をもたせる
入力のセットから出力が定まる（冪等&純粋）ため処理結果の予測可能性が高い
個々の式が正しければそこから導出される状態も正しい
状態遷移
現在の状態のパターンマッチングによって次の状態に遷移する
基本的にprev→nextの漸化式で表現する
→Immutable Modelの状態遷移の対応関係をしめた「状態法則」を見出すこと
1. SSoT(唯一の情報源)と状態の依存関係を整理する
2. 関係(relation)と関連(relationship)を見つける
3. コアの状態を導出可能な式にする
4. 式をつないで状態遷移パターンを定める
状態法則の表現例
全てImmutable Modelとして表現するが依存値の単位が異なる
上位概念に対する式
objectに対する式
1センテンスに対する式
objectまたはfield
依存変化をトラッキングする
関数の入出力を繋いだ式