Shouldn't data on useQuery be non-nullable when using suspense: true?

[sunwrobert]

It's a bit inconvenient to assume that data will always be null, especially if I'm already wrapping it in a Suspense. Am I wrong for assuming it should be non-nullable?

[kitten]

data is nullable for several reasons:

• In the presence of errors data may be not set when when an error prevented the GraphQL query from executing
• data may be null when an error bubbles up from a non-nullable fields (nested in all non-nullable fields)
• when the query is paused on a null-result (this is a bindings/UI concept exclusively)
• when a cache-only operation has no result
• when suspense is selectively disabled for a single query (again, a bindings/UI concept)

So, even with Suspense, there's several cases that prevent data from being non-nullable.

[Emmahchinonso]

@kitten please I'm still new to urql but how do I invalidate a query that returns null because of some checks on the backend during server side rendering(using suspense). This null query cache is propagated to the client side and I want to invalidate the query so it refetches with the correct data, especially on page reloads. The only option I can think of is to pass a requestPolicy to the query call but I'm not sure if that's the right way

[Emmahchinonso]

Hi @kitten, I saw this comment that suggests using pause, the issue I have with this is that it causes hydration errors. The usequery call returns undefined on the server side but returns data on the client side. I'm rendering different elements based on the useQuery return values hence the hydration issue.

I expected the useQuery call on the client side to return undefined initially and then make the graphql call but that's not what's happening. The fetching and stale states are also false for some reason even when an api call was made.

[musjj]

In TanStack Query, useSuspenseQuery guarantees that the data is always defined: https://tanstack.com/query/latest/docs/framework/react/reference/useSuspenseQuery

Same object as useQuery, except that:

• data is guaranteed to be defined

Is there a reason why this works for TanStack?

[JoviDeCroock]

I am assuming that tanstack will throw the error it encounters and does not account for partial data. In GraphQL there is the possibility to have partial-errors where i.e. a sub-tree or item in the list bubbles their error up but the rest of the response is correct.

[jtomaszewski]

What if we had ignored the possibility of partial data. So that we could have the non-nullability of data when suspense is enabled.

This could simplify some applications a lot.