しゅみは人間の分析です

いらんことばかり考えます

Reactのstateに何を入れるべきか問題

暫定の結論

60fpsの世界を実装したことはないのでその辺は対象外です。
いかにも当たり前っぽい結論になりましたね。また何か思いついたら日記にしていきます。

考えたときの思考をシリアライズしたもの
  • UIの状態とデータの状態に大きくは分けたくなる
    • どちらにもまたがるケースが出てくる
    • リストの順序
    • 決めの問題として、データに寄せてもよい
  • 後から仕様変更で、UIの状態からデータの状態に移動するのがダルいという意見
  • 究極的にはすべてをデータの状態として管理するのは可能ではある
    • Fluxループを回るのがダルい
  • 二つの問題が混ざっているのに、境界がはっきり引けない系の問題
  • UIの状態とはなんなのだろうか？
    • UIとはなんなのだろうか？
      • データを人間にわかりやすく伝える手段
      • データを人間にとってわかりやすく操作する手段
      • データの閲覧・操作が目的
    • データをUIとして表現する
    • データとその表現、特に表現を共有するとはなんなのか？
      • データとデータの依存関係
      • observerパターンでは？
      • Rx川の予感
        • 実際にネイティブアプリ界では流行ってるらしい
    • なんでUIの状態に依存関係が？
      • たぶんデータそのものに依存関係がある
      • 目的はデータの操作で楽をさせてあげるため
      • 依存関係をもとに自動化をしている
    • データに依存関係あるなら、データレイヤで変化を伝えればいいのでは？
      • ほとんどのケースではこれが正しい
      • しかし
        • Fluxループを回るので遅いケースがある
    • 依存関係のないUIの状態
      • ある
      • モーダルが開いてるよ
      • フォーカス当たってるよ
      • コンポーネントの中に隠蔽した状態でよい
    • 結論
      • 原則としてUIの状態はデータの状態から自動的に求められる
      • データを操作するのがUIの目的
      • データの依存関係は原則データレイヤ、つまりドメインモデルの操作で解決されるべき
      • データに紐付かない、中間状態としてのUIの状態はコンポーネントに持ってよい
      • コンポーネントが表現する状態(props)と、コンポーネントが内部に隠蔽する状態(state)がある

Scrapbox上で寝ながら考えたところたいへん捗りました。
見返してみると、最初の方は問題がうまく分割されていないために用語が複数の文脈を背負っていたり、最初と最後で矛盾しているかのように見える文章になっていますが、問題が解決されていく様とはこんなもんなのでいいとしましょう。

*1:軽量なUIを作るのならば、ルートコンポーネントのthis.stateにドメインモデルの状態を保持するのも例外的に許容できる