(next-urql) - Different pages reuse the same URQL Client instance, even if they're not intended to.

[edygar]

urql version & exchanges:

• "@urql/core" "^2.4.4"
• "next-urql": "^3.3.2"

Steps to reproduce

1. Create two pages with two intended different resulting ClientOptions
2. Navigate from one to another

Expected behavior A different instance of URQL Client on the new page is created.

Actual behavior Due to this bit of code the client-side instance gets arbitrarily reused.

Even though there's resetClient, it gets exposed only after react rendered and after the render' requests are done, from getInitialProps there's no way to control whether we want or not to reuse the instance, even if we return a new urqlClient, because of this.

[danyalaytekin]

Could this previous refactoring, which remains in the codebase, also be a problem? @kitten sounded unsure in their review:

• https://github.com/FormidableLabs/urql/pull/857

I thought about raising this in a new ticket but decided to put it here as it's potentially related. The comment still says // Serialize the urqlClient to null on the client-side. That was the whole story before the change (since there was a window guard further up) but not afterwards (since it's now in a place where isServer can be true). So either the comment seems mistaken, or the code is correct and the comment outdated.

[kitten]

This is intended behaviour. We reuse the Client because we preserve the cache. This is really a basic behaviour of a fetching/state client, so we don't want that cached state to be lost on route transitions. If you do want to have a request sent on every transition, then you'd basically want to use the urql Client without a cacheExchange.

[kitten]

Closing due to inactivity. Let me know if that helped or if there are more questions you have, or are trying to achieve something specific ✌️