moved the data constant outside of the ssrExchange closure

[sebaholesz]

Summary

In scenarios when ssrExchange was called multiple times, each time a new reference of the data constant was created. However, within the ssr function defined inside ssrExchange, only the very first reference of the data variable was used, which caused a mismatch. For example, in Next.js this caused a bug where during client-side navigation, if a query was prefetched inside getServerSideProps of the page the user has navigated to, the result was stored in the SSR cache, but it was never used, as it was filled into a different object (different reference) than the one that was used originally. Because of this, the URQL client searched for the data in the wrong place and it never found it. This caused the query to be refetched and the layout to shift because of the missing data.

Set of changes

The data constant (object to which the SSR-prefetched data is stored) was moved outside of the ssrExchange closure to ensure just a single reference being used.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3ac82a3

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[kitten]

This change isn't quite right and is a small misunderstanding of how SSR hydration basically has to work.

We can't hoist const data: Record<string, SerializedResult | null> outside of ssrExchange because that would mean that we create a global record. This would mean that, on the server-side, all results are combined from every request. That's explicitly not what the ssrExchange is for.

In fact, that's basically exposing clients to results that have been generated for different requests, and in fact breaks the ssrExchange guarantees.

To also note this, it's very rare that an exchange will have global state in general, since all state should be scoped to a specific Client. The ssrExchange is somewhat of an exception even, since we create it separately to the Client to gain access to some of its methods, but that's still state that's scoped per instance.

[sebaholesz]

@kitten I understand and agree that this was rather a hotfix that did not make any sense. After more investigation and looking into the problem, as well as trying to reproduce it inside a minimal Stackblitz, I was able to write my thoughts down and would appreciate your opinion on this: #3653