jotaiコードリーディング 2回目
改めてstore.tsを読む
更に読みやすくなっててすごい
createStore
このスコープで保持されるJSの変数という意味でのステート
atomStateMap
メインの、atomとその状態を示すやつ
mountedMap
mountedを示すやつ
pending系
pendingStack
pendingMap
これは、pendingという別概念があり、そのためのもの
おそらくwriteタイミング、および非同期周りのためにある
addPendingDependent
setAtomState時に呼ばれる
すなわち、setAtomValue or setAtomError時
pendingStack
push,popタイミング
syncは、writeAtom
asyncは、writeAtomState
すなわち、書き込みタイミングでstackを作るということ
書き込んでいるatomのpendingを保持したい
flushPendingで消す
集めたpendingなatomらに対して
mountedされたなら、listener叩く
依存先もmountする
すなわち、pendingってのは、書き込みごとの一時置き場で、それらのmountまわりの処理をまとめてよしなにやるためのもの
観点
read,write
jotaiにおいては、atomの依存関係は、動的にtrackingされる
なので、read, writeというのは、その動的なtrackingを行うきっかけのタイミング
なので、内側のprimitiveな挙動という作用を発火するので、readという字面とは裏腹に、(mount, unmount等)副作用的な挙動が発生する
mount,unmount
dependencies, dependents
データとしては、Dependencies = Map<Atom, AtomState>として表現され、AtomState内に保持される
つまり、依存元側から、先を保持する
一方で、値を変更時は、依存先側から元へfan outする必要がある
これはMountedというデータ型で保持する
なので、状態変化時にrecomputeDependentsをする
promiseの処理
cancelとか、
setAtomValueOrPromiseあたりまだわからん
continuePromiseとか
pending
continuePromise
nextでつなげたら、そっちのpromiseで無理やりresolveする感じかなあ?
まだpendingなpromiseに対して、あとからきた別promiseで上書きしたいとき?
cancelPromise
呼び出し
unmount時
setAtomState
mountDependencies
中身は読みやすい
呼ばれるところ
flushPending
setAtomValueOrPromise
if (mountedMap.has(atom) && prevAtomState.d !== nextAtomState.d) {
要するにmountedMapに乗せたが、state.dに変化あったらこれを呼ぶ