[Experimental] Support promises as fallback data

[shuding]

This PR introduces the ability to accept promises as fallback data for SWR read hooks. The behavior is that the resolved value of the promise will be used as fallback instead of the promise itself.

The resolution of the promise is implemented via use which means that it will suspend the upper boundary.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[promer94]

I think we should avoid upgrading react to a specific version here?

we currently have a spearte testing workflow for react@canary at https://github.com/vercel/swr/actions/workflows/test-canary.yml

so i guess we could create a sperate jest config for this and only test it in react canary ?

[vpontis]

@shuding I think this broke something with our types.

We modify the type of data when creating our hook based on useSWR so that we know data is defined if you specify fallbackData. This is a pretty nice type improvement.

  // We can be confident that data will be nonnull even if the request fails,
  // if we defined fallbackData in the config.
  data: SWRConfig extends { fallbackData: Response }
    ? Response
    : Response | undefined;

This is part of the bigger hook:

import { AxiosError } from "axios";
import { useCallback } from "react";
import useSWR, { KeyedMutator, SWRConfiguration } from "swr";

export type Refresh = () => Promise<unknown>;

type GetApi = any;

export const useZmClient = <
  Path extends keyof GetApi,
  Request extends GetApi[Path]["request"],
  Response extends GetApi[Path]["response"],
  SWRConfig extends SWRConfiguration<Response>,
>({
  path,
  pause,
  args,
  swrConfig,
  additionalKey,
}: {
  path: Path;
  pause?: boolean;
  args?: Request;
  swrConfig?: SWRConfig;
  additionalKey?: string;
}): {
  // We can be confident that data will be nonnull even if the request fails,
  // if we defined fallbackData in the config.
  data: SWRConfig extends { fallbackData: Response }
    ? Response
    : Response | undefined;
  error: AxiosError<{ code?: string }> | undefined;
  mutate: KeyedMutator<Response>;
  refresh: Refresh;
} => {
  const swrKey = [path, JSON.stringify(args)];
  if (additionalKey) {
    swrKey.push(additionalKey);
  }

  const { data, error, mutate } = useSWR(
    pause ? null : swrKey,
    () => null as any,
    swrConfig,
  );
  const refresh = useCallback(async () => {
    await mutate();
  }, [mutate]);

  return { data: data!, error, mutate, refresh };
};

This will now give a type error:

components/hooks/useZmClient.tsx:53:5 - error TS2769: No overload matches this call.
  Overload 1 of 12, '(key: string[] | null, fetcher: ((arg: string[]) => FetcherResponse<Response>) | null, config: SWRConfigurationWithOptionalFallback<SWRConfig> | undefined): SWRResponse<...>', gave the following error.
    Argument of type 'SWRConfig | undefined' is not assignable to parameter of type 'SWRConfigurationWithOptionalFallback<SWRConfig> | undefined'.
      Type 'SWRConfig' is not assignable to type 'SWRConfigurationWithOptionalFallback<SWRConfig> | undefined'.
        Type 'SWRConfiguration<Response>' is not assignable to type 'SWRConfigurationWithOptionalFallback<SWRConfig> | undefined'.
          Type 'SWRConfiguration<Response>' is not assignable to type 'SWRConfigurationWithOptionalFallback<SWRConfig>'.
  Overload 2 of 12, '(key: Key, fetcher: BareFetcher<Response> | null, config: SWRConfigurationWithOptionalFallback<SWRConfig> | undefined): SWRResponse<...>', gave the following error.
    Argument of type 'SWRConfig | undefined' is not assignable to parameter of type 'SWRConfigurationWithOptionalFallback<SWRConfig> | undefined'.
      Type 'SWRConfig' is not assignable to type 'SWRConfigurationWithOptionalFallback<SWRConfig> | undefined'.
        Type 'SWRConfiguration<Response>' is not assignable to type 'SWRConfigurationWithOptionalFallback<SWRConfig> | undefined'.
          Type 'SWRConfiguration<Response>' is not assignable to type 'SWRConfigurationWithOptionalFallback<SWRConfig>'.

53     swrConfig,
       ~~~~~~~~~

I think it would be nice to either:

1. update SWR types to be smart about the data type based on if fallbackData is an object
2. update the configuration types a bit to support what I'm trying to do above

Or maybe I'm doing something else wrong. If you'd like me to open an issue or try to fix something, please let me know!