Better Typing support when suspense is enabled

[huozhi]

Some restrictions can be applied to swr when suspense is enanbled:

• key can’t be falsy
• fetcher can’t be null
• data can’t be undefined

Note: this is tricky as TypeScript can’t handle inherited configs, and those can be dynamic in the runtime.

[FDiskas]

Already fixed in https://github.com/vercel/swr/releases/tag/1.0.1-beta.0 ???

[shuding]

No it’s not added yet. I don’t think this can be handled by TypeScript because configs can be inherited from SWRConfig. What we can do temporarily is to support the per-hook configuration.

[Svish]

My suggestion would be to just separate the two. Either a separate hook, or just a separate import like from swr/suspense or something like that.

That way you could simplify the regular hook by removing all suspense related stuff from there, and the suspense hook could be written with perfect types and no non-suspense related stuff.

[karol-majewski]

What should happen if useSWR from swr/suspense was used alongside a global config contradicting it?

<SWRConfig value={{ suspense: false }}>
  <App />
</SWRConfig>

[Svish]

Can't you already do that? Doesn't useSWR currently take suspense as an option, which overrides the default config?

[shuding]

By definition, useSWRSuspense should override the global config of suspense: false.

Also, it would be great to cover more use cases such as waterfall (#5, #168) and dependents with this suspense hook.

Waterfall:

useSWRSuspense(key1)
useSWRSuspense(key2)

Dependent (should it fallback to the suspending state if the first resource changes upon focus?):

const { data } = useSWRSuspense(key1)
useSWRSuspense(data.id)

[karol-majewski]

OK, so your proposal is for the new useSWR to override default settings with { suspense: true }. That makes sense.

How should then conditional fetching be solved? Suspense users should also be allowed to make conditional requests, therefore key cannot be required to be truthy. If key can be falsy, then that implies data will sometimes be defined, sometimes not. This doesn't leave much room for improvement on the type level.

We can, however, leverage safestring to determine when Suspense-powered requests are guaranteed to deliver a response every time — which is when key is guaranteed to be truthy. Suggested improvement (simplified for brevity):

declare function useSWR<T>(key: string): { data: T  };
declare function useSWR<T>(key: string | null): { data: T | undefined };

declare function safestring(strings: TemplateStringsArray, ...args: Array<string | number>): string;
declare function safestring(strings: TemplateStringsArray, ...args: Array<string | number | null | undefined>): string | null;
declare function safestring(strings: TemplateStringsArray, ...args: Array<string | number | null | undefined>): string | null;

declare const customerId: string | null;

useSWR<Response>(safestring`/api/v1/customers`).data;              // Response
useSWR<Response>(safestring`/api/v1/customers/${customerId}`).data // Response | undefined

TypeScript playground

[MoSattler]

Is there any workaround right now, where I can tell SWR that the data will be guaranteed to be defined, thanks to suspense and error boundaries?

[Svish]

Is there any workaround right now, where I can tell SWR will be guaranteed to be defined, thanks to suspense and error boundaries?

Best solution now is probably to make your own typed wrapper hook of useSWR which makes sure things work the way you want. We've done this for react-query, works well.

[MoSattler]

@karol-majewski

If key can be falsy, then that implies data will sometimes be defined, sometimes not.

I don't know the internals of useSWR, but couldn't one in principle use overloading to infer if data is defined or not? Something equivalent to this?

function useSWR<Data>(key:undefined, fetcher: Function): {data: undefined};
function useSWR<Data>(key:string, fetcher: Function): {data: Data};
function useSWR<Data>(key:string | undefined, fetcher: Function): {data: Data | undefined} {
    // code
}

[karol-majewski]

@MoSattler There is a problem with such an overload. Reason: key being a string is not enough to infer that data will be defined.

Consider this common use case:

useSWR(`/customers/${customerId}`, fetcher)

If customerId is nullish, the key is indeed a string, but the fetch call loses its meaning and as such should not be made. Therefore, data should not be expected to be defined even though the key is a string.