Avoiding screen tearing requires passing snapshots+stores together?

[stephenh]

I'm looking at moving our ~large-ish app over from mobx to valtio, with the idea that useSnapshot will be great for avoiding React 18 concurrent rendering / screen tearing issue + just much more ergonomic than mobx's HOC/Observer.

However, because we use ~per-page/per-form stores (instead of a global store), a lot of our code just passes mobx stores/proxies around as props:

function AuthorList({ store }: props) {
  return <Observer>{() => {
    // AuthorView will reactively read/write the `a` the child mobx proxy
    return store.authors.map(a => <AuthorView author={a} />);
  })}</Observer>
});

Or our super-reusable TextField that takes a FormField.value/setValue mobx proxy and wraps it all of the boilerplate label/errors/validation that is the same for every form:

function TextField({ field }: props) {
  const onInput(text) = field.value = text
  // wrap in Observer...
  return <div> label boilerplate, errors boilerplate {field.value}</div>
}

I.e. code that really can't "just import the store from a static / module variable".

I'm really excited about valtio removing the <Observer> component + observer HOC + etc. cruft by having a single useSnapshot:

function AuthorList({ store }: props) {
  const snap = useSnapshot(store);
  return snap.authors.map(a => <AuthorView author={a} />)
});

But now the AuthorView is "stuck" with a snapshot and cannot invoke any mutations on it (like if the AuthorView has a form and actually wants to edit the name).

So that makes me think I should pass the store through and use useSnapshot in child/leaf components:

function AuthorList({ store }: props) {
  // don't bother with useSnapshot? obviously need it for reactivity...
  // const snap = useSnapshot(store);
  return store.authors.map(a => <AuthorView author={a} />)
});

function AuthorView({ author }: props) {
  // _now_ useSnapshot
  const snap = useSnapshot(author);
  // but I can still mutate the store when needed
  const onClick = () => author.clicked++;

...but now I'm susceptible to screen tearing, b/c I might have ~100 authors and the first 50 get v10 of their snapshot, but the last 50 get v11 (like if some global operation completed between the first 50 & second 50, which changed some field on all authors).

Granted, I really don't know if this is a big deal or not, i.e. how often it happens in practice/should I really care? It seems like React's core team thinks it is a big deal, given they added useSyncExternalStore API specifically for (AFAIU) avoiding screen tearing...

But, useSyncExternalStore assumes it is called once at the top of the component tree, and all components under it use its snapshot. I.e. the child components can't have their own useSyncExternalStore calls w/o misalignment/tearing from the parent.

It makes me wonder if React could provide a "global frame count" sort of number, that works similar to like a game drawing frames on the screen; it draws frame 1, then frame 2, then frame 3.

Then Component A's useSyncExternalStore would not just get "whatever the super-latest snapshot is", it would be able to "get me the snapshot for frame 1". And later when Component B renders (but still for the "frame 1" rendering pass), it's useSyncExternalStore could return a snapshot specifically for "frame 1", even though the store might have been mutated mid-render.

...that thought experiment aside, without React providing this "the current frame number is X" for multiple useSyncExternalStores (or useSnapshots) to coordinate, I'm back to the only way to prevent screen-tearing is to take a snapshot at the top of the component tree and then use it as deeply through the tree as possible.

...but then also pass the store, for when I want to do mutations. But something like <Author snap={author} store={author2} /> seems pretty less than ideal.

Do you have any thoughts/recommendations on this tension? That snapshots must be created once high-up, but leaf components will still want the store.

My only current "...maybe good? not sure..." idea is that if proxyWithClass, with a bind trick for this in setters/methods == the mutable proxy, would let me pass around "snapshots that can still mutate the store".

---

Ha, so after thinking that through, now I am (slightly) worried about stores & snapshots looking "too similar"; let's say an engineer writes:

function AuthorList({ store }: props) {
  return store.authors.map(a => <AuthorView author={a} />)
});

And I say "no, sorry, that's not reactive, you need to go through useSnapshot", and they say "got it!" and write:

function AuthorList({ store }: props) {
  const snap = useSnapshot(store);
  // i'm good now!
  return snap.authors.map(a => <AuthorView author={a} />)
});

Good! But then they write AuthorView:

interface AuthorViewProps {
  // no indication of "author store" or "author snap"
  author: Author; 
}

function AuthorView({ author }: props) {
  // i was told to always useSnapshot to get reactivity!
  const snap = useSnapshot(author);
  return <div>{snap.firstName}
});

They have re-snap'd the snapshot. :-/

...I dunno, should useSnapshot detect being passed an "already snapshot", and just return it as-is? I get that ideally the user should know what they have, but it seems like it would be confusing to beginners, when they get a prop, how to tell "what is it? a store? a snapshot?" and then conditionally know whether they should useSnapshot it or not.

---

Maybe I just want a useStore hook that merely subscribes/renders to the store proxy and doesn't even use snapshots.

The rationale is that if I'm passing stores as props anyway (and using many per-leaf-component useSnapshot calls), why bother with a snapshot? I'm already going to get screen tearing across components (each component gets the super-latest snapshot instead of a consistent "snapshot for frame 1"), so why bother making the copy?

Granted, a naive useStore would re-render on any subscription/notifyUpdate...but that's a) probably not terrible, and b) maybe usage tracking could still be worked in...i.e. returning a compare-proxy against the store itself instead of the snapshot.

---

Approaches:

• 1 top-level useSnapshot
  • pro: avoids screen tearing
  • con: best when children are read-only/unclear how to pass child snaps+stores
• N leaf-level useSnapshots
  • con: risks screen tearing
  • pro: easy for child to make mutations
  • con: why make snapshots if we're tearing anyway
  • con: confusing for "was i passed a store or a snapshot"
• a new useStore hook
  • con: accepts screen tearing as a risk
  • pro: avoids cost of snapshot copies
  • pro: no confusion of "is this a store or snapshot"
• proxyWithClass with bind hack for unified store+snapshot behavior
  • pro: avoids screen tearing since child use the snapshot
  • con: still confusing "was i passed store or snapshot" / do i useSnapshot or not

Hrm.

---

Fwiw I'm going to hit "Start discussion", but I realize this is a super long question; definitely np if you just scan it, not respond right away, and let me sit on it for a bit and mull things over; even just writing up the discussion to guide my own thought process has been very helpful. :-)

Thanks!

(Fwiw I tried to scan the some existing Valtio-based apps to see if they had an obvious answer for this/patterns to follow; I scanned your remote-faces sample app, but it seems like it's using module-level states + per-component useSnapshots, so I think if we're being really pedantic it would suffer from screen tearing? But again not sure if that really matters.)

[dai-shi]

Hi, I didn't read everything, but one note is, to make it reactive, we useSnapshot and then pass a store.
Also, having key={} would really help in React. So, I'd assume author has id prop.

function AuthorList({ store }) {
  const snap = useSnapshot(store);
  return snap.authors.map(((a, i) => <AuthorView key={a.id} author={store.authors[i]} />)
});

It's a bit tricky but should work the best. (There should be other solutions.)
You also want to wrap AuthorView with React.memo.

[stephenh]

we useSnapshot and then pass a store.

Yep! You're right that .map(a, i) is likely the best way to handle it.

My biggest questions are:

a) Won't this approach (passing the store as a prop) risk screen tearing when AuthorView does their own getSnapshot that might be newer?, and

b) If I'm not going to pass the snapshot to children anyway, why bother making a snapshot in the first place?

(I know today useSnapshot is currently necessary to be reactive, but afaiu the primary goal of snapshots is avoiding screen tears--which if it doesn't do that for apps that pass stores as props anyway, then maybe reactivity could be achieved w/o the cost of the snapshot.)

[dai-shi]

a: should be fine. useSyncExternalStore in useSnapshot takes care of it.

b: to make AuthorList reactive to the length of authors and the item order of authors.

[stephenh]

a: should be fine. useSyncExternalStore in useSnapshot takes care of it.

...really? I thought the idea with concurrent rendering is that we might have:

1. I have 100 components in my tree to render
2. The first 50 render and have useSyncExternalStore called, get version 1 of a snapshot
3. React stops and lets a mutation happen
4. The last 50 render and have useSyncExternalStore called, which get version 2 of a snapshot

...unless the behavior of React concurrent mode is not that "the 100 component-tree will have their render-to-build-VDOMs interrupted" but merely that "building the VDOM is still done synchronously, but reconciling the VDOM to the DOM is done concurrently".

Hm, no, the React docs heavily insinuate it render/VDOM building itself that is concurrent.

Or maybe the VDOM building can still be interrupted, but after interrupting and going back to finish "the last 50 components", React quickly asks the 1st 50 (via each of their useSyncExternalStore.getSnapshot fns) and says "hey did your external store change since last time? If no, I'm not going to re-render you, but if you say yes, then shoot I have to re-render all 100 to make sure we have a consistent view".

Damn. I bet that is it?

If so, that is amazing, and I apologize for you having to lead me to that conclusion through a long Q&A ticket. I swear I've done a non-trivial amount of googling on useSyncExternalStore/React concurrent rendering/etc, but haven't found anything that explains the "how it actually works" like I described above.

[stephenh]

Okay. I understand now.

facebook/react@06f98c1#diff-cfa128bca4d5b386950dc89bf856c5b071a8a081cf7edce12802a415eef1e72dR1327

facebook/react#17334 (comment)

Calling a setState (forceReload) in useLayoutEffect is how React prevents the first now-stale render from being painted. That's pretty cute.