perf(suspense): optimize handling of multiple suspense/useSubscribe

[welkinwong]

Strictly speaking, this is indeed a bug. While it doesn’t break the app, it can lead to a poor user experience in specific scenarios:

When two or more identical subscriptions are active simultaneously, unmounting one of them may cause the other subscription’s nearest Suspense boundary to revert to its fallback state.

This issue typically occurs in complex applications.

---

This PR primarily introduces a reference counter. The subscription will only be cleared when the counter reaches zero, indicating that no components are actively consuming it.

[welkinwong]

before:

after:

[nachocodoner]

Not sure if it's related, but it might be. In the forums, an user reported a failure in [email protected], including the recent changes we merged around Suspense, useFind, and useSubscribe. One user said the react-router-ssr-demo doesn’t load data at all when using 3.0.5-beta.0. The demo code uses Suspense and the hooks, so it could be closely tied to those changes. Not sure if it’s covered by the fix in this PR or if another fix is needed.

Could you check? I’ll test it when I get a break from the latest bundler work.

[welkinwong]

@nachocodoner

After investigation, I believe this is an implementation issue in the v6 version of the react-router-ssr module. The current implementation uses React 18's renderToPipeableStream with onAllReady for completion signaling, but the stream doesn't wait for all asynchronous data to resolve.

I've already filed an issue regarding this behavior in the react-router-ssr repository: renderToPipeableStream in server.js Does Not Wait for Async Content Inside Suspense