fix: Support React Suspense in collections

[devongovett]

Fixes #6182, fixes #7535

There were two issues with our collection implementation with Suspense:

1. React sets display: none on items inside a suspense boundary, while the fallback is visible. We didn't implement this, so it resulted in the loading indicator being displayed alongside the existing items rather than replacing them. I fixed this by tracking whether an element is hidden. Hidden elements are kept in our fake DOM, but they are removed from the collection.
2. The previous transaction count could get out of sync with react if a render was aborted. Turned out we don't need this anymore after fix: Improve collection update performance #7905, which now relies on React to queue the render instead. When triggering an update, we just return a clone of the previous collection, which forces React to re-render due to object inequality. When React actually does re-render, we update the collection. This way there's no inconsistent states due to partial updates.

[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]

lgtm, tested in macos chrome/ff/safari

[selrond]

@devongovett thank you! Any idea when this will be released?

[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

[LFDanLu]

LGTM, Table story seems to behave properly with reactTransition turned on/off, approving for further testing

[Danieljs-codes]

Is there a way to use this now?

[yihuiliao]

@Danieljs-codes you should be able to use the nightly to get this fix

[selrond]

@yihuiliao how should one install it? @nightly refers to version 3.0.0 according to npm

[snowystinger]

The nightly is an exact version, all dependencies you use from our libraries should point to the same nightly version. That is says '3.anything' is irrelevant and more has to do with ease of tracking the same nightly across the entire repo where our first packages happened to be 3.0's for legacy reasons.

3.0.0-nightly-cfe79d329-250401, to read a nightly version, just ignore the 3.0.0, then 'nightly', then the git commit hash to main, then the date it was merged. You can choose the latest one, or a more specific one that you're looking for based on that information. There are some skipped git hashes because the nightly only builds once a day.

[selrond]

@snowystinger thanks for the clarification!

Would it be ok to include this info somewhere in the readme?