generated at
フロントエンドと時空

> 空間の分割統治
>  コンポーネント、仮想DOM
>   宣言的UIのおかげで楽になった
>
> コンポーネントに分けて考える時、コンポーネントが通過する時間を意識する必要が生まれた
>  functional component時代のreact hooksがこれを扱う
>   hooksで、コンポーネントの生存消滅時の挙動や、コンポーネントがレンダリングを跨いだときの某を記述できる
>   これは時間を扱うことを意味する
>
> rxjsが実は依存グラフの実現は楽だったはず
> なんで廃れた?
>  大衆に対して抽象論を押し付けてしまったからでは?
>
>   任意のものをデータの流れとして捉えるのは別に良い
>    しかしこれは、時間軸のみを意識することになる
>     アプリケーションの木構造を快適にハンドリングする手法がなかった
> 上記の仮想DOM移行の流れにおいて、rxjsが何をどう解決するかを提供できなかった
>
>  ただ、rxjsはそもそもなにかの特効薬を提供する義務はないし、必要なところではとても役立つはず
>   何を解決できうるのかはライブラリユーザが各自で考えればいいだけのこと
>
> そうこうしてるうちにjotaiとか便利な方法が生まれた
>  実現したいことは近いが、実装方法がかなり違うはず
>   recoilの実装はよくわからん
>
>   APIの違いについては意識しておきたい
>    recoil, jotaiのapiはすごい直感的

koushisa
時空とは
>時間と空間を合わせて表現する物理学の用語
現代のUI(SPA)の状態は四次元的な状態を持つ
静的なHTMLとJS(二次元)
UI=HTMLとJSの時間遷移(三次元)
時系列で変化するUIのI/Oとその状態管理(四次元)
時空の抽象となる実装が必要となる
クラスやMVCという階層構造はGUIシンクロニシティ(共時性)を表現するのに適していない
欲しいのはグラフ構造
Reactにおける時空の抽象
時間
空間
対しStreamはそれ単体で時空を抽象した
Hot, Coldやオペレータにより、機能ごとのデータフローを時系列, 空間, 座標レベルで分離する
Hot
常にI/Oを垂れ流す
Cold
Streamのパイプラインを形成する
空間分割はコンポーネントに任せる
同じデータソースでもコンポーネント固有のデータフローを構築できる
依存グラフを持っている
参照されたときに全ての依存グラフを同じ時間軸で計算する
量子力学的な特徴があるなkoushisa
依存グラフの値はキャッシュされ、グラフに変化がない場合は再計算せず同じ結果を返す
GUI開発においてはRxよりもAtomic State Managementのほうが扱いやすいというのは確かにkoushisa
たくさんのオペレータを覚えなくていい
参照透過性を持ちつつもコンポーネントのレンダリングに紐付いている
それが常に最新の値であることが保証されている
非同期か同期か問わず、ステートの計算が終わってからrenderフェーズを走らせることができる

四次元のデータは多胞体と呼ばれている
三次元に生きている人間には知覚(クオリア)できない
投影」という作業が必要
Rxでいうオペレータはこの投影類似性がある
時間のリストに対するtake, map, filter, reduce, pipeなど...
koushisaは覚えきれない
Selectorという概念は人間に優しいインタフェースを持つがStoreが正規化されていないと深刻なパフォーマンス問題を抱える

そもそも四次元の事象を三次元の頭で考えるのには無理がある