Two useStore hook prototypes

[stephenh]

Hi @dai-shi ; per other discussions, I've been experimenting with how we'd adopt Valtio in our current mobx app.

And, in particular, the ergonomics of "when do I pass a snapshot / when do I pass a store", which I agree the current best practice afaiu is your suggestion of:

{snap.books.map(b, i) => <Book book={store.books[i]} />}

After thinking about, what I like about mobx is not having this dichotomy between "the read instance" + "the write instance" + "you pass them both around".

So I've experimented a little bit with a useStore hook that still does usage-based re-rendering of a component, but tracks accesses to the store directly, without introducing the snapshot as "a new/different identity" that users have to juggle/reason about.

I'm at the point where I'll share the experiments, and if you're interested, I'd be happy to keep iterating on the core ideas, but also I'm fine if you consider them out-of-scope for Valtio.

I have two branches, the 1st useStore is "pretty clean code" but uses affectedToPathList in a "not just debugging" manner to impl a non-snapshot-based version of isChanged:

https://github.com/pmndrs/valtio/compare/main...stephenh:valtio:add-use-store?expand=1

And the 2nd branch is "very! ugly code" and makes super hacky/proof-of-concept changes to both proxy-compare (there is a local fork of proxy-compare in the branch) + vanilla.ts to make the hasDirtyReads calc as fast/efficient as possible.

https://github.com/pmndrs/valtio/compare/main...stephenh:valtio:add-use-store-2?expand=1

The two hacky changes are:

• Changing proxy-compare to take an onAccess callback instead of an affectedMap so that we can record each access directly in our data structure, instead of having to recover them later via affectedToPathList
• Changing vanilla's Op to include the original/most-leaf store so that the root subscriber knows not just the path of books/0/title but also has the books/0 instance itself

Note that I'm not at all proposing these proxy-compare/vanilla.ts hacks land as is, they're merely concept/discussion stage to drive the useStore experiment.

In terms of "does this belong in Valtio?", my pitch would be:

• I think the 2nd branch in particular "checks all the boxes" in terms of great ergonomics (imo!) + usage-based rendering + changes the identity of proxies on change so that deps/useMemo still "just work" as users expect (which is a great feature of snapshots & useSnapshot)

• While the "separation of snapshot+store" is today fundamental to Valtio, and admittedly many React state libraries/React itself, personally I'd pitch that, as a "proxy state library", it'd be within the mission statement to provide a "single proxy identity" solution, given my admittedly biased assertion that that is why many users of "proxy based" state libraries use them in the first place.

But totally your call!

I've already spent way more time than I'd wanted, so if you're not interesting in the useStore prototypes, that's actually not a bad thing b/c I can go back to "real work". :-D

[dai-shi]

You want to check #620 and #635 by @sarimarton, if you haven't. They are so insightful. Also, #609 is an idea from mobx.

tldr; I like your work on these experiment, and encourage you to work as a third-party library, in valtio ecosystem.

Valtio exists for the separation of state and snapshot. My invention here is, the separation fits well with React immutability model (and for useSyncExternalStore API), and it separates the concern of implementation to make the code more maintainable.

I've already spent way more time than I'd wanted

That's actually convincing my philosophy. valtio only cares about "set" handler, and proxy-compare only cares about "set" hanlder. This separation, I believe, simplifies things. And, proxy-compare is more reusable.

The original intention of valtio isn't a replacement for mobx, but more to position itself different from mobx. But, now we see several people want it as the replacement, which is good.
At this point, the separation of state and snapshot is the design of valtio, and it's not the goal to hide it. The useProxy util is a nice workaround to half hide the separation.
I haven't really tried, but by combining valtio and proxy-compare tightly, it might be possible to develop an ideal proxy state solution. (though, I'm not sure if/how it's concurrent friendly. #635 seems promising.)
I'm happy to modify valtio so that it's more extensible (I think unstable_buildProxyFunction is the most extensible, but there can be a better way). Like the one you did in dai-shi/proxy-compare#54 is nice, even though it's not necessary for the current usage.
I would love to see the valtio ecosystem expands.

[sarimarton]

This write-up actually mostly backs up my findings: reactwg/react-18#70

Valtio is currently level 2, and a simple useState with a one-time dirty checking during useLayoutEffect is equivalent to level 3. What's not mentioned there, is that uSES not only badly de-opts initial renderings, but subsequent ones as well. It shouldn't be used at all 😃

[sarimarton]

In React source code, this might give a clue about uSES's sync update nature vs. useState/useReducer:

uSES:
https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberHooks.js#L1790
https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberHooks.js#L1808

function forceStoreRerender(fiber: Fiber) {
  const root = enqueueConcurrentRenderForLane(fiber, SyncLane);
  if (root !== null) {
    scheduleUpdateOnFiber(root, fiber, SyncLane, NoTimestamp);
  }
}

vs. useState/useReducer:

https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberHooks.js#L1218

(It just marks stuff)

[dai-shi]

fwiw, the difference between uSES and useState + subscription is, for now, mount time tearing only. But the mental model is uSES is guaranteed by React for a longer term, but user land solution isn't.
The difference can be observed in http://github.com/dai-shi/will-this-global-state-work-in-concurrent-rendering

That said, I personally like useState solution and developed a library called use-valtio.

[sarimarton]

the difference between uSES and useState + subscription is, for now, mount time tearing only

No. Mount-time tearing plus uSES's de-opt sync updates, which outright blocks concurrent rendering features.

As you state in the use-valtio README, it can't be used with startTransition. Mount-time tearing can be solved with dirty checking, I don't see any risk in that. Once you have a consistent external input (subscription), it's not possible to have any tearing. The React team undercommunicates the bad performance of uSES, and it shouldn't be recommended for libraries at all. I'll open an issue on React about it. E.g., any app with Redux is totally out-of-game for concurrency, and I actually stepped into this problem earlier, and only now (!) I understand why startTransition didn't work for me. How on earth could someone has a tearing issue, whereas the feature which could trigger any tearing doesn't work at all?

BTW, the invisibility of this problem shows how insignificant concurrency as a use-case is.

[stephenh]

useState + subscription is, for now, mount time tearing only

Fwiw I don't understand the term "mount time tearing only" ...

If @dai-shi you mean how useValtio works:

https://github.com/dai-shi/use-valtio/blob/main/src/index.ts#L66

That impl AFAIU doesn't even have "mount time tearing" is has "mount time missed updates", which is worse than just tearing, b/c at least tears resolve themselves on subsequent renders.

Why wait until useEffect to subscribe?

If you immediately subscribe via an onMemo, you won't have any missed updates (which is maybe what you meant by "mount time tearing"?)...

But across a large component tree, you'll still have tearing on either 1st mount or Nth renders because nothing is coordinating that ~100 components all calling get(snapshot(proxy, handlePromise), path) across a wide component tree will all return the same consistent / point-in-time snapshot.

[stephenh]

This write-up actually mostly backs up my findings: reactwg/react-18#70

I had seen that before, but re-reading now with a bit more experience was very useful; thanks!

This annoys me as well, and the speculative nature of the discussions in this area.

Well, that makes me not feel as bad for flailing about. :-)

and a simple useState with a one-time dirty checking during
useLayoutEffect is equivalent to level 3.

True, although fwiw I believe the way React's useStates work internally, a dirty-check against a useState basically cannot fail during a useLayoutEffect.

B/c my reading of the reactwg link was that all setStates are magically queued to "the next render", and so the useLayoutEffect dirty check would always see its original/potentially-state state, as that lets the consistent/non-torn render finish. That's Level 3.

Avoiding tearing effects can be fully achieved without uSES; any subscription model
works, and dirty checking during useLayoutEffect protects against initial tearing
as well

Unfortunately I believe any dirty check during useLayoutEffect basically is a poor mans uSES.

I.e. see one of their initial semi-user-land/semi-native implementations of uSES that does just this:

facebook/react@06f98c1#diff-cfa128bca4d5b386950dc89bf856c5b071a8a081cf7edce12802a415eef1e72dR1327

And then this comment which AFAIU says "any setState during useLayoutEffect (pre-paint) aborts the render" --> this is exactly what uSES does --> this is exactly the "longer rendering" of Level 2.

So, I haven't pulled up your latest useExactProxy demos, but AFAIU if you adopt this "dirty check during useLayoutEffect", you should have guaranteed consistency (no initial tearing/etc)...but also the same terrible "longer rendering" perf as uSES / useSnapshot.

---

I have bothered @dai-shi about this several times (albeit never this succinctly :-), but I believe the huge "miss" with uSES is that it doesn't give the library any indication of which render is currently being executed.

I.e. per the reactwg "useState is magically level 3 b/c mutations are pushed to 'the next render'", React has not exposed anyway for 3rd party state libraries to participate in this "current render / next render" capability.

If they did, i.e. by passing a "render count" / "frame number" to uSES.getSnapshot() (so it switches from "always return me the latest state" to "return me the consistent state for render/frame N"), Valtio would really come into its own, b/c it could align its own snapshots (Author v1/Author v2/etc) with React's own internal state/render tree, and mean that multiple uSES calls across separate components but within the same render could "just know" to get the same-potentially-stale-but-consistent-snapshot.

Which is exactly what useStates do, and is exactly what's required for Level 3. Let the stale but consistent render finish.

I'm just really surprised the React core team missed this--like before, the uSES that uses the "set state in useLayoutEffect" trick was perfectly doable in user-land...so, sure, they brought the uSES impl internal--but did nothing to actually leverage the power they now have (by being internal)...i.e. exposing the current render/frame number, which is something a userland uSES could never hope to do.

AFAICT, until React/uSES exposes this sort of "render counter" capability (either via a uSES.getSnapshot(frameNumber) param or a new hook...useConsistentExternalStore?), Valtio, Apollo, and any other 3rd party state system will never be able to achieve Level 3 b/c they're not on equal footing: they have no way of competing/integrating with "this render vs. the next render" capability of React's internal state.

@dai-shi sorry to keep bugging you about this, but if you have friends/connections on the React core team, I'd be interested in their thoughts (and your thoughts as well!) on this uSES "miss".

[sarimarton]

Once they fix uSES in the linked issue, it'll be a convencience API, but not a necessity.

[stephenh]

This is, on a language-level, an always-false condition

Of course, my original "useLayoutEffect reading a useState" was meant solely as illustration of why React's built-in useState doesn't have tearing / doesn't need dirty checks; I think maybe you took it a little too literally, b/c yes that example is nonsensical.

You can't know what keys to subscribe to in a useMemo during render

Sure; my useStore prototype fixes that by subscribing immediately to all changes (which don't necessarily cause a re-render), and then after render you can intersect "changed vs read" to see if dirty reads occurred.

But your approach works as well, with the initialValue-is-dirty check.

Also, subscription is a side-effect which needs tear-down.

Sure, it can be unsubscribed in a useEffect, even though its started in useMemo.

Tearing is not possible on subsequent renders.

I don't believe that...

With a subscription model where listeners are called in sync

Sure, each listener will call setCount(c+1) on all 100 components, which will all be queued together for "the next render", but are you saying it's guaranteed that during the next render a) no store mutating callbacks, and b) no timer/ajax/etc mutation will occur during the re-render of the 100 components?

That seems implausible; surely during the 2nd/3rd/Nth render, React could:

1. Re-render the first 50 (who see proxy-v2 now, great)
2. Interrupt its rendering to unblock the browser
3. Something else does yet another mutation
4. Re-render the last 50 (who see proxy-v3--now we're torn again

Just like it can happen on the 1st render; what makes the 2nd render special, that this is gauranteed to not occur?

The only way to produce tearing is to have different renders reading different values over time

Sure. That's what I've shown in my steps 1-4. Just b/c we asked for all 100 components to render at the same time (via the subscription notifyUpdate being synchronous and calling setCount(c+1) for all 100 components in the same tick) does not guarantee all 100 components will have their JSX evaled synchronously. Right?

You'd have to convince me that, after the subscription does setCount(c+1), that the 2nd render is not concurrent across all 100 components, and basically React switches into synchronous rendering after the initial mount/initial render.

Does it do this? Where do they say that?

[stephenh]

Ah, I see maybe what you're trying to do/thinking...in useExactProxy, your subscribe is pushing a cached version of data into each component.

So maybe that is how you think all 100 components will be aligned to "the same consistent/non-torn view"?

But I still think you could have:

1. Change happens and 100 subscribeKeys callbacks are called
2. All 100 components put proxy-v2[firstName] into their cache, synchronously, their caches are consistent (good for now!)
3. All 100 components ask to re-render via the setCount(c+1) (in the same batch)
4. React renders the first 50 components, who use proxy-v2[firstName]
5. An ajax call completes, React interrupts mid-re-render, and causes proxy-v3 to trigger
6. All 100 components have their callback fired, and update their local caches to have proxy-v3[firstName]
7. React renders the last 50 components, whose ref now has proxy-v3[firstName]

It's torn.

...that said, if instead of using setCount(c+1) I wonder if, on change, you pushed a new snapshot into your local state, i.e. remove the counter+ref approach (b/c the ref will always be latest and not aligned to the React internal state tree) and do setSnapshot(snapshot(...)), b/c that evaluates synchronously, now you're guaranteed that all 100 components will use the same proxy-v3 snapshot b/c React will bundle their setSnapshots into a single coherent/non-torn re-render.

[sarimarton]

I see now what you mean, that react flushes out a stale state before it starts over. I wanted to make a test for this, essentially recreating Abramov's clock demo, but darn, it's not yet released...

Caveats
...
If there are multiple ongoing transitions, React currently batches them together. This is a limitation that will likely be removed in a future release.

https://beta.reactjs.org/reference/react/useTransition#usetransition

So for now it's essentially a debounce. (Why did they release it like that?...) We can't demo stale flushes until this limitation is lifted. And you're right, snapshots will be the answer.

By the way, I can't even recreate any kind of deprioritizing. Even with transitions batched, the input box should be responsive here:
https://codesandbox.io/s/concurrency-clock-demo-stgk78?file=/src/App.js

But it's not. What am I missing?

---

useMemo is an interesting idea, but you can't rely on that.

You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. Write your code so that it still works without useMemo — and then add it to optimize performance.

https://reactjs.org/docs/hooks-reference.html#usememo

[stephenh]

that react flushes out a stale state before it starts over

Right!

And that is what useSES does not let us do--say "yes, this snapshot is stale...but it is consistent with the rest of the render you're currently executing, so just it flush out". Which is Level 3.

But it's not. What am I missing?

I have not fully reconciled startTransition into my mental model yet, so not sure...

Other than, it creates a "new branch" of React's internal state, and that branch is allowed to "take awhile to render" (i.e. block on a suspend/promise) and the "technically stale but still responsive" non-branched state will cover for it, handling key-presses, etc, until the new branch is finally rendered and takes over.

useMemo is an interesting idea

Ah yeah, good reminder; my latest / 3rd useStore prototype already does not subscribe in useMemo (the 2nd one did iirc), and instead subscribes on access / while the JSX is rendering:

https://github.com/pmndrs/valtio/compare/main...stephenh:add-use-store-3?expand=1

So still prior to useLayoutEffect so it won't miss updates.

[sarimarton]

Relevant issue: facebook/react#25191

[dai-shi]

"return me the consistent state for render/frame N"

To my understanding, that is not enough for branching. We need to queue updates (like c=>c+1), not results.

[stephenh]

We need to queue updates (like c=>c+1), not results.

Afaiu it's not queuing updates that is the problem...it's reading the current state (calling getSnapshot) "at render N / frame N" across ~100s of components.

If I've got 100 components all calling snapshot(proxy), but 50 get proxy-v1 and 50 get proxy-v2, we are fundamentally torn (each component by itself its own locally "current" view, and it will not miss any updates), b/c nothing is coordinating "they are all proxy-v1" without useSnapshot via useSES spamming the pre-paint check of "make sure everyone has proxy-vLatest before I commit!".

Perhaps your assertion is "don't allow c=>c+1 to happen in between the first 50/last 50", but:

a) That's exactly what setStates do (not by doing synchronous rendering, but maintaining an immutable (consistent) tree of state for a given render), but
b) useSES assumes the external store is 100% mutable, and the mutations could happen via AJAX responses / browser window size changes / local storage changes / all sorts of things that can't be "queued to the next cycle", and
c) useSES assumes the external store is fundamentally mutable / non-versioned, so any drift is non-recoverable, and must de-opt the entire render (for all 100 components, until we get a render pass where all 100 have magically aligned on the same proxy-vN)

What's special about Valtio is that your external store actually is versioned, so you can recover from drift by keeping a stale-but-consistent snapshot. If useSES would give you the info you need to "always return proxy-v1 for render N", even if technically render N+1 is already queued up to use proxy-v2. At least let render N finish.

[dai-shi]

I'm not sure if we are on the same page. I just wanted to point out something from my experiments.
https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering/blob/620e09dc82225905cf137680d592b9b14256d995/__tests__/all_spec.js#L148
That test behaves differently between useState and current uSES. If you are saying to make uSES behave like useState, that's really something I've wished for a long time.

What's special about Valtio is that your external store actually is versioned

It is versioned, but not branched.