fix: Improve performance of collection updates in React transitions

[devongovett]

Fixes #8094

This improves performance of collection updates that occur in React transitions, e.g. startTransition. The performance issue was caused by the following behavior described in the docs for useSyncExternalStore:

If the store is mutated during a non-blocking Transition update, React will fall back to performing that update as blocking. Specifically, for every Transition update, React will call getSnapshot a second time just before applying changes to the DOM. If it returns a different value than when it was called originally, React will restart the update from scratch, this time applying it as a blocking update, to ensure that every component on screen is reflecting the same version of the store.

Essentially, React would call our appendChild to update the fake DOM, we'd trigger the useSyncExternalStore subscription, and React would interrupt itself and start over. This would occur for each element that was rendered, resulting in many renders.

This behavior seemed unexpected at first, because in general, React's commit phase is blocking. Only the render phase is concurrent. After inspecting the React source code, it turns out that they actually do some DOM updates during the render phase, which can be interrupted. Specifically, they create new DOM elements during the render phase, and then the commit phase is just attaching new subtrees to the existing DOM, and performing updates/removals.

The solution is to avoid triggering collection updates for elements that are not in the document yet. Once React starts the commit phase, it will attach these disconnected nodes and that will result in a single collection update instead of interrupting render.

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-19
• View the storybook-17
• View the storybook-16
• View the S2 storybook
• View the documentation

[snowystinger]

description of what we should see if it's working vs failing?

[devongovett]

fast vs slow

[snowystinger]

ok, I pulled down the PR and reverted the changes in Document. It is definitely painfully slow without the update to Document.
It'd be nice if we could actually test this so we'd know if we ever introduced anything which made it slow again.
I wonder if this can be replicated in a jest test with real timers and if it exceeds some threshold then we fail.

[devongovett]

maybe. I'd be worried about the timing variability on different machines though

[nwidynski]

@snowystinger Added this in #8209. Should be safe as far as timing is concerned 👍

[snowystinger]

ok, I pulled down the PR and reverted the changes in Document. It is definitely painfully slow without the update to Document.
It'd be nice if we could actually test this so we'd know if we ever introduced anything which made it slow again.
I wonder if this can be replicated in a jest test with real timers and if it exceeds some threshold then we fail.