Recoil
facebookが作った状態管理ライブラリ
まだ出たばっかでベータ
公式サイトの動画を見るのが手っ取り早い
https://www.youtube.com/watch?time_continue=200&v=fb3cOMFkEzs&feature=emb_title
扱いたいデータはatomという単位で定義する
Redux時のStoreの一つのpropertyが一つのatomになる
viewのツリーとは独立してデータを定義してhooks経由で引っ張ってこれる
https://gyazo.com/38b265924e17529b26791bad4f091170
これはリスト内の選択した要素のboundingboxを得る例
https://gyazo.com/4684ef386b390149bf5f51418d9208a7
もととなるstateだけでなく、特定の計算で決まるような(vueでいうところのcomputedみたいな）のもこうやってatomで定義できる
全然知らないけどVueにも似たようなのあったよなー、と思ってたけどcomputedかmrsekut.icon
view上の異なるコンポーネント上で同じ値を見たいときに便利
https://gyazo.com/a6ba924e007df80a41e8770cd9324ce7
親側で再レンダリングが走らなくて良いらしい
たしかに上からバケツリレーすると再レンダリング走りそう
AがあってBがあって、これらを使ってい計算してCが決まる、みたいなことはよくあるmiyamonz.icon
Unityの新しいDOTSというアーキテクチャで採用されている
計算グラフといったほうがいいかも？
reduxみたいなやり方だと計算グラフみたいなのが面倒？
jsonのような形で元のデータを持ち、関数で求める
useEffectやメモ化を使って再計算を減らすことは可能
recoilのやり方は記述が楽
最近リアクティブプログラミングやりたくてRxJSをちょっと触ったけど、全然こんなに快適に書けなくてウオアアアってなってたmiyamonz.icon
もととなる値とcomputedな値は、それを使うview側にとってはどっちも単なる変数なので、同じように扱えるのは楽
計算グラフは外側のatom()で作れるのも快適ぽい
異なるコンポーネント上で値を参照する事自体は、context 使えばできるので素のcontextなりreduxなりでもできそうな気がする
useStateはfluxなのか、という質問とだいたい同じになる
違う気がするmiyamonz.icon
計算グラフを作れるところとか
でも対立する反対の概念ということじゃなくて、そもそももうアーキテクチャが違うじゃんという感じではなかろうか
reduxにはsingle source of truthが原理として述べられてたけど、fluxにこの主張ってあったっけ？
recoilはsingle source of truthじゃなくなってる？
そうだと思うが、でもあんまり関係ないmiyamonz.icon
single source of truthといって、色々まとめ上げたroot objectがあっても、その中がglobal空間になるだけでは？
ReduxHooksを使ったReduxでは確かにそう。
global stateを同じファイルに書いているか(ReduxのStore)、同じフォルダに書いているか(Recoilのatom)の違いでしかない(本質的には無)
viewの外側にステートを持ちづらかった（各種コンポーネントにステートが散逸していた）のが辛かったのを何とかするために、single source of truthを考えるとメリットがあった
あーーーーーーーー、なるほどmrsekut.icon*4
Hooksによってそこの障壁が消えたのかmrsekut.icon
useContextで遠い親(だいたいrootとか)にあるProviderから持ってこれるようになったおかげですねmiyamonz.icon
recoilはそのstateを全部外側においておけるので、散逸もクソもなくなって普通にjsのオブジェクトとして扱える
あとはパフォーマンスのために計算を色々頑張っているだろうなとと思っている
react自体もkeyとかメモ化とかそういうので頑張ってて、これをviewじゃなくてstateの方にもやっているのではないかと想像する
reselectとかuseSelectorの第2引数がやっているのパフォーマンス調整を自動で(?)やってる感じになっている
あんまりパフォーマンス詳しくないので雰囲気でそう思っていますmiyamonz.icon
atomにもselectorにもkeyってあるし
何のためにkeyって手動指定なんだろうmrsekut.icon
きっとreactのkeyも自分で指定しなきゃいけないのと同じ理由だとは想像できるmiyamonz.icon
動的に変わるリストにおいて、再計算時にそれが同じものであるかどうかは人間が決めないと、リコンサイラが計算飛ばしていいかわからないからだっけ
だからrecoilにおけるatomも動的に変わる場合に、ただしくkeyを指定すれば再計算が省ける
逆に言うとkeyがないと再計算が毎度走るのかな？
recoilが良さそうと思う人、次の時代のデファクトになるぞと感じた人がどうするか
突然使ってみる
既存のstate管理を、可能な範囲で計算グラフを作る（リアクティブな形にする）形でリファクタリングする
外部jsライブラリを実装見ながら動かす最適解知りませんかmiyamonz.icon
recoilの内部実装も追ってみたいのですが、npm i するとdistが入ってきて見づらい
素振りリポジトリ上でgit cloneしてソースマップ付きでビルドとかはできるが、vscodeのコードジャンプはできない