useSuspenseQuery polling

[sophstad]

Issue Description

Based on its documentation and typing, useSuspenseQuery lacks support for polling via pollInterval. However, it actually works! Seems like this is because the hook makes a call to watchQuery with whatever options are specified. We'd love to keep using this, along with nextFetchPolicy, which hits the same issue. Is there any reason not to offer official support?

My reproduction includes a call to useSuspenseQuery with a pollInterval set, which yields a type error. The query resolver logs each time it is called, so you can observe polling in the browser console.

P.S. Would be awesome to offer a TypeScript-ready CodeSandbox template!

Link to Reproduction

https://codesandbox.io/p/devbox/eloquent-wescoff-k44smw?workspaceId=ws_8rvGwpeFUisRWig4LxWzQN

Reproduction Steps

No response

@apollo/client version

4.0.3

[jerelmiller]

Hey @sophstad 👋

The decision to omit polling was intentional, mostly due to the semantics of a suspenseful query. The issue isn't that we can't poll, its how we manage the loading state during a poll. For other fetch operations (initial fetch, refetch, fetchMore), we cause the component to suspend when it goes into the loading state.

This will likely be a horrible user experience if we do this out of the box. useSuspenseQuery relies on React's startTransition API in order to avoid showing the loading state (which you determine as a user of the API when to apply this), but we can't use that with polling because we don't have any way to tie into a state transition that would prevent the component from suspending.

That leaves us with avoiding suspending, but what happens if you want to show some sort of loading indication when it is in the middle of polling? We do export a networkStatus from the hook, however one of the tenants of a suspenseful hook is that you don't have to handle loading states in the component itself.

It's this split in logic that we haven't been able to agree upon, hence why we haven't yet officially supported polling in the hook. We intentionally didn't add it to the TypeScript types, because we didn't want to signal that its a supported option.

I'm sorry I don't have a better answer for you at the moment, but hopefully that helps explain why this has been trickier to solve!

[jerelmiller]

P.S. Would be awesome to offer a TypeScript-ready CodeSandbox template!

Oh and yes! We've been meaning to do this for a while, but haven't found the time to do it. Contributions are welcome 🙂