Batch multiple writeAtom operations

[yf-yang]

https://codesandbox.io/p/sandbox/great-scott-x28y5r

Say there is an atom that depends on multiple atoms. When one of those dependencies are updated, its perfectly fine. However, when I need to update multiple atom "simultaneously", there exists an intermediate state where the downstream "get" is triggered with only one dependency atom is updated and the other is remained the same.

I know current behavior does not affect rendering. The use case is that I'd like to add some assertion in the dependent atom, but when two dependencies are updated simultaneously, there exists an intermediate state that breaks the assertion while the beginning/ending state still satisfy the assertion.

So, are there some api to achieve that? If not it's OK, I'll try to figure out other solutions.

[dmaskasky]

Related: #2827

[yf-yang]

Much better than I expect! Go for it 👊

[dmaskasky]

Its a WIP. But I think the approach is sound.

I think new behavior should be:
Atoms accessed with get (and all of their dependencies) are recomputed in place and unmarked from pending recompute. Their dependents (deep) are marked as pending recompute.

Atoms updated with set (and all their dependents) are marked as pending recompute.

All pending recompute atoms are recomputed in flushPending.

[yf-yang]

I realize one thing, the PR is different from what I expect.

Your PR is willing to solve that when an atom is set, its downstream atoms should only be computed once.

I'm expecting that when setting two or more atoms, their downstream atoms should be computed once. #2827 still not resolve this issue because flushPending will be called each time a dependency's set is called.

To achieve that, either some auto-batching mechanism is needed (I think React wraps all the event handlers to make sure event handlers are auto batched), or some explicit transaction-like batch function should be created.

[dai-shi]

It's our design decision not to introduce batch function. If we were to add it, it should be a third-party library in https://github.com/jotaijs.

[yf-yang]

Yep, seems it's not a good idea to do something like that, as people rarely need such a feature.

[dmaskasky]

We have sorely missed you 🥲

I need help with:

1. this - Recompute defers to flushPending where possible
2. jotai-scope reimplementation using store.unstable_derive
3. get in writeFn should not add dependencies (currently it does for atoms deeper in the tree)
4. stack overflow issues with read and write for large atom graphs (replace recursion with iteration)

The PR is still a WIP, but it is not necessary to recompute in-place unless something is read with get.

[dai-shi]

Hey @yf-yang, haven't heard from you for a while. How's everything? Would you still be able to help jotai-scope project?

[yf-yang]

Hi, I'm good! I've been checking out jotai-scope issues now and then, though not always promptly (and @dmaskasky responds pretty quick 👍), but there doesn't seem to be much to do. If there's anything I can help with, let me know. I saw that issue #2827 is also trying to tackle the complex jotai-scope scenario.

[yf-yang]

Oh I haven't check discord for several months 😲

[dai-shi]

Yeah, we use Discord for some discussions. It seems like you left my server. We can use GithHub discussions if you prefer.

[yf-yang]

Is it poimandres? I'm still there. I just downloaded a discord desktop app, that could be better.

[dai-shi]

It's another one: https://discord.gg/MrQdmzd

[dmaskasky]

Batch functionality added in #2827