Valtio's current capabilities and what's possible in concurrent React

[sarimarton]

This thread is opened to put on record all the features we encountered in the past days and evaluate them in the context of concurrency support. I'll update this table once something react-related comes up, and add comments below.

Feature	Relevance	Current useSnapshot/useProxy	useExactProxy
Cross-hook ref stability useWhatever(x) === useWhatever(x)	Not interesting	❌	❌
hook ref stability without mutation		✅	✅
hook ref stability on child set	Needed for idiomatic dep lists	❌	✅
hook top level shallow ref stability	Little relevance	✅ useSnapshot ❌ useProxy	❌
hook deep ref stability	Needed for destructuring style in render	✅ useSnapshot ❌ useProxy	✅
Key-based tracking	Needed for idiomatic dep lists	❌	✅

[sarimarton]

"Key-based tracking" is highly related to "useSnapshot ref stability on child set", but I put them separately, because one might be feaible and the other not.

It means that tracking proxy usage in render works with the following logic:

• any prop is accessed, we're subscribing to its change with an Object.is check with the previous value

The current tracking works in a more complex and more unpredictable way:

• it takes all the most specific props which were accessed, filtering out the parent props
• the resulting filtered list of props are subscribed with any change on their tree (in case they're objects)

This leads to 2 problems:

1. It requires special awareness from the developers, because they need to have a full overview of all the proxy references in a component in order to know the impact of a single reference.
2. It breaks idiomatic react dep list usage which the linter will highlight:

function Cmp() {
  const store = useProxy(_store)

  useEffect(() => {
    fetch(api).then(response => store.slice1.data = response)
  }, [store.slice1])
}

Here, the linter mandates to put store.slice1 in the dep array, and the component will go into an infinite request loop.

[sarimarton]

@dai-shi , I recommend to your attention my newest version and findings.

I think I tackled all the pain points:

• Key-based tracking (as opposed to the current tree-based one)
• Ref stability being on par with the original proxy (content change keeps the parent key ref intact)
• Concurrency support (no tearing)
• Extremely fast

Here is my new code:

https://codesandbox.io/s/new-useexacttrackerproxy-xvfuu3?file=/src/useExactProxy.ts

My thought process had a few corner points:

(1) useRef can be used, only that it can't be accessed in render. But it's okay to mutate a render-closure variable, and pick the values from there in a useEffect

(2) Concurrency support is mostly handled on a theoretical/speculative basis from library authors without actual tests to see how the lib behaves. See for example: reduxjs/react-redux#1860. The question in reduxjs/react-redux#1860 (reply in thread) is pretty much relevant and stays unanswered.

There are reference and tearing effect tests at https://codesandbox.io/s/new-useexacttrackerproxy-xvfuu3?file=/src/useExactProxy.ts

You can see that useExactProxy has better performance characteristics as well, compared to useSnapshot.

There are also some tests at https://codesandbox.io/s/valtio-snapshot-unstable-reference-bug-forked-jmio2d?file=/src/CurrentUseSnapshot.tsx which I linked elsewhere earlier, showing how buggy useSnapshot is currently.

My strategy was to implement an adequate tracking/scheduling logic, and use tearing tests to prove concurrency-compliance. As for tearing tests, I only found the one you showed in the react conf video (about mouse X), so I copied it and changed in a way that it involves proxy updates instead of mouse positions.

The tearing tests quickly showed that only those implementations are prone to tearing problems, which don't have a proper scheduling logic. The mouse test was such. I made a vanilla proxy component, which obviously reproduced the tearing. useSnapshot didn't tear, but interestingly it showed an unwanted characteristics: it's super slow, because it goes through every step of the iteration (can't explain it better). I don't know if it's intended from your perspective, but it definitely doesn't reflect what startTransition is meant to be about. On the contrary, my new useExactProxy shows the desired characteristics: the costly renders are skipped, while the proxy updates and the useState call finish quickly.

The logic has the following steps:

1. During render, collect the dependecy keys and their initialValues into a closure variable (dependencies). Dependencies are all the key paths the switch proxy encounters. This is a simple, predictable logic, which doesn't involve specificity checks.

E.g., when a render has the following references:

foo
foo.bar
foo.foo.bar.baz

the following dependencies are collected: foo, foo.bar, foo.foo, foo.foo.bar and foo.foo.bar.baz. It is completely agnostic to destructuring practices.

2. In a useEffect, subscribe to these keys, pick their initial values, put them in a cache and schedule an update whenever any of the dependencies change.

And that's it.

2 acknowledgements:

• This strategy is completely different from proxy-compare. As I explained earlier, tree-subscription is mostly useful outside of react, but once you collect a complete list of dependencies, it doesn't make sense anymore to tree-subscribe to any of it. I remember you mentioned proxy-compare was so essential, that you basically built the library around it, so it's gonna be a different library, which I accept - I can put all these in a different library (it's just harder to propagate and market etc.)

• Another thing which might be hard to let go is useSyncExternalStore. I understand that you almost made this lib as a reference implementation to uSES. But apart from there, it's hard to see its value. I saw the RFC discussion about uSES, where they mention nuances, but it goes back to my earlier point, that without tests which prove the weakness of a particular implementation, I see little value pursuing uSES. On the other hand, currently I do have a test which proves the inferiority of the current version of useSnapshot. uSES seems to go against the proxy approach in general. uSES needs ref stability on the top level, and once anything changes, the full snapshot tree reference must change too. This conflicts with idiomatic dep lists...

In my mind, uSES is only relevant once it's the only thing which solves tearing. I'd love to see an actual test which demonstrates this. I could've added a set trap to the switch proxy to prevent in-render mutation, but I didn't even care about it. IMO it's not the lib's concern to prevent certain antipatterns. My goal was to have a mutation-based proxy syntax, which is predictibly tracked, performant, referentially stable and has no unforeseen underlying conflicts with idiomatic react usage.

[dai-shi]

I'm not following all the comments, but I think I understand what key-based tracking is.
What I think key-based tracking is missing is something like this: https://codesandbox.io/s/new-useexacttrackerproxy-forked-6xh7ro?file=/src/App.tsx
I'm not saying tree-based tracking solves it. It actually does not. I'm saying both are suboptimal.

What's really nice about your idea is the switching proxy, which makes key-based tracking feasible.
To me, there still seems a pitfall with key-based tracking even without concurrency. So, my job is to find a breaking case for key-based tracking (even with switching proxy).

[sarimarton]

That console.log shouldn't be triggered, I'm quite certain in that. That causes infinite useEffects easily:

useEffect(() => {
  fetch(api).then(response => {
    state.foo.bar.baz = response
  })
}, [snap.foo.bar])

This is idiomatic react (it's not with snap, but it is with the switch proxy which translates to the above), and it doesn't work now with Valtio, because it starts fetching infinitely. The react linter mandates state.foo.bar to be added to the dep list:

const state = useProxy(originalState)

useEffect(() => {
  fetch(api).then(response => {
    state.foo.bar.baz = response
  })
}, [state.foo.bar])

[dai-shi]

I think idiomatic react is to use immutable state.

const Component = () => {
  const [state, setState] = useState({ slice: { data: null }, ... });
  useEffect(() => {
    console.log('slice is changed')
  }, [state.slice]);
  const handleClick = async () => {
    const data = await fetchData();
    setState((prev) => ({ ...prev, slice: { data } }));
  };
  // ...
};

It think we are disagreeing each other from different basis.

[dai-shi]

Here's some comments on the table as of now.

Cross-hook ref stability useWhatever(x) === useWhatever(x)

useSnapshot should be stable, no?

hook ref stability on child set

What's this?

hook deep ref stability

useSnapshot is actually stable for deep children, but usage tracking can break it.

[sarimarton]

useSnapshot should be stable, no?

No, if there are two sibling hooks in the same component, they will be separate snapshots, it's documented here too:

https://github.com/dai-shi/react-tracked/blob/main/website/docs/caveats.md#proxied-states-are-referentially-equal-only-in-per-hook-basis

But this quite an irrelevant thing.

hook ref stability on child set
What's this?

When there is a proxy set, like state.foo.bar.baz += 1, then its corresponding snapshot reference on the parent node snap.foo.bar will change reference as well, which it shouldn't do. It hijacks dependency lists, which the linter mandates.

useSnapshot is actually stable for deep children, but usage tracking can break it.

Yes, it's stable when the proxy is unchanged, but once there's a set, it shows the above problem. But this point was more about the switch proxies, I update the table to show the distinction between useSnapshot and useProxy.

[dai-shi]

useSnapshot should be stable, no?

No, if there are two sibling hooks in the same component, they will be separate snapshots, it's documented here too:

https://github.com/dai-shi/react-tracked/blob/main/website/docs/caveats.md#proxied-states-are-referentially-equal-only-in-per-hook-basis

Oh, yeah. I forgot that proxyCache is per hook.

hook ref stability on child set
What's this?

When there is a proxy set, like state.foo.bar.baz += 1, then its corresponding snapshot reference on the parent node snap.foo.bar will change reference as well, which it shouldn't do. It hijacks dependency lists, which the linter mandates.

I get it and it's by design.

[dai-shi]

To me, there still seems a pitfall with key-based tracking even without concurrency. So, my job is to find a breaking case for key-based tracking (even with switching proxy).

It's surprisingly working well. It's different from my expectation with key-based tracking.
How does this even work??
https://codesandbox.io/s/new-useexacttrackerproxy-forked-1zfljt?file=/src/App.tsx

It updates "text" correctly. There are extra re-renders, but it should be solvable.

[sarimarton]

Which button? The fetchData button in https://codesandbox.io/s/new-useexacttrackerproxy-forked-1zfljt?file=/src/useExactProxy.ts ?

[dai-shi]

Yeah, I would like to make Random number won't change if text doesn't change.

[sarimarton]

Well, you're adding a new reference for sure. If you do

    $store.slice.data.text = 'hello'

in the callback, the random number won't change anymore.

It might be parametrizable to only subscribe to primitive (leaf) nodes, but to me this is expected. data is being read in render, and it got a new value. I expect a re-render to make sure the new value is read out.

[dai-shi]

So, my conclusion is that we are based on different paradigms (our expectations are different). You are probably tired of hearing that valtio is developed for concurrency and that means to match with useSyncExternalStore (formerly useMutableSource), so snapshots are a must feature. Using uSES is a guarantee for concurrent safe (but only level 2 ref. btw, any userland solution is level 1 at best.) for the future versions of React (which is a belief at least for now.)
Please don't take it wrong. Your idea is actually very good. It's just different. I highly encourage you to create a third-party library. I'm also developing a third-party library, valtio-signal which depends on valtio/vanilla, but not useSnapshot.

[sarimarton]

Thanks, no worries!