Data cannot be undefined when suspense = true

[Svish]

Wanted to try enabling Suspense Mode in a project today, and ran into a typing issue. The responseInterface of useSWR is typed like this:

export type responseInterface<Data, Error> = {
  data?: Data
  error?: Error
  revalidate: () => Promise<boolean>
  isValidating: boolean
}

In Suspense mode, data is always the fetch response (so you don't need to check if it's undefined). But if an error occurred, you need to use an error boundary to catch it.

But I do need to check if it's undefined. 😕

I guess the interface in Suspense Mode should be more like this?

export type responseInterface<Data> = {
  data: Data
  revalidate: () => Promise<boolean>
  isValidating: boolean // <-- Assuming this is still useful for revalidation
}

Not sure how to best solve this though, but it should somehow be solved. I don't feel like starting to throw ! or // @ts-ignore stuff everywhere I use useSWR with suspense mode. 🤔

[Svish]

I see there's already quite a bit of function type overloading on useSWR, so duplicating all of those for suspense and non-suspense, is probably not the best idea...

Maybe it would be better if the "Suspense enabled" version of useSWR was pulled out as its own function, useSuspensedSWR, or something like that? 🤔

[enzoferey]

Any updates on this ? #168 looks related but nothing about it.

[Svish]

@enzoferey #168 seem to be an extension of the API to perform/wait for multiple requests "in parallell"? Don't think I really need that as I think suspense works fine like it does now. Only problem is the Typescript typings for the suspense variant, as mentioned in this issue.

[illeatmyhat]

Even including current type hackery in the latest TypeScript 3.9, I think it's not possible to elegantly represent a situation where the types branch on the assumed value of Suspense. I've made an issue about it some time ago.
Your only decent option is likely to make a separate function like useSuspendedSWR

[shuding]

Closing this and we will be tracking related problems in #1412.