SSR Exchange 'cache-and-network'

[yoshiwarab]

Hi I'm using the the ssr exchange with next-urql to hydrate SSR data client-side as described here. I have set the request policy within my useQuery call to be 'cache-and-network' however, I think when the data is rehydrated through the ssr exchange, it does not register as a cache hit so no network call is ever made. Is this the intended behavior and if so is there anyway around this without manually re-executing the query?

[JoviDeCroock]

Yes, the time difference between ssr rehydration is very small hence why we don't do that currently. Is there a case for this?

EDIT: The fix was done in a PR #1852, we've now introduced the option of specifying staleWhileRevalidate as an option

[yoshiwarab]

I think it'd be reasonable to allow the ssrExchange to revalidate data. However, if we'd do that I'd explicitly wouldn't make it require cache-and-network but instead add a proper "stale-while-revalidate" path to it, since that'd avoid a default that'd refetch excessively

Oh, what would that look like? SSG data is given an expiration time and then only refetched on the client if the time has passed?

[kitten]

Oh, what would that look like? SSG data is given an expiration time and then only refetched on the client if the time has passed?

Exactly, I think that'd actually be quite a nice built-in feature.

[JoviDeCroock]

Hmm, would next add some type of timestamp or would we do so? I assume a timestamp on the original entry in this JSON map is what you're implying 😅

[JoviDeCroock]

Will be solved by #1852

[yoshiwarab]

Amazing, thank you!