rexecuteQuery escapes Suspense boundary

[StevenLangbroek]

Hey folks, found a little issue with suspense:

urql version & exchanges:

version: [email protected]
exchanges: graphcache + built-ins

Steps to reproduce

• Go to https://codesandbox.io/s/gifted-bohr-honuf?file=/src/App.tsx
• After data comes in, click on the "Load again please" button above the list

Expected behavior

Refetching a query should trigger the suspense boundary

Actual behavior

Refetching a query completely bypasses Suspense and leads to an uncaught "exception" (the promise that should be suspended on) 🤷

[kitten]

My first thought here is that I don't think it's possible for us to prevent this from happening as this behaviour is a side-effect that can only be driven into triggering the Suspense boundary if it re-renders.

However to re-render the function would have to alter some state to trigger React to update. We'd only want that to happen once though, but we can't control this to be a guarantee to happen only once, as React doesn't make this guarantee itself anymore.

So long story short, I believe the two patterns — Suspense and executeQuery — are incompatible with one another.

What we could do is force executeQuery to never trigger any suspense behaviour internally though

[StevenLangbroek]

What we could do is force executeQuery to never trigger any suspense behaviour internally though

That sounds to me like how it should behave. I would expect we would need to handle result.fetching then, where it would specifically deal with just refetching state. What do you think?

[StevenLangbroek]

Suspense without react@experimental's useTransition could not possibly support this I think, no (because the render tree is blown out, I would imagine you lose urql-internal state)

[kitten]

@StevenLangbroek I do think you'd have to handle it; However, it would mean that the previous content would stay mounted, which actually is rather nice as far as loading behaviour goes, since that means if it's not handled, the content still doesn't break.

[StevenLangbroek]

Yep agree!