Better way for conditional data fetching.

[yash-sharma01]

Currently, useSWR allows conditional data fetching by passing null as a key parameter.

This approach works fine in almost all cases. However, there are other packages that handle conditional data fetching in a completely different manner. For example, RTK Query from Redux Toolkit has a boolean parameter in the options object called "skip" that can be used to skip the request for certain conditional logic.

// useSWR approach
const { data } = useSWR(postId ? `/api/posts/${postId}` : null, fetcher);

// RTK Query approach 
const { data, error, status } = usePostsQuery(postId, { skip: !postId });

The RTK Query approach looks much cleaner and maintainable when we have a long key/URL and multiple conditions to check.

It would be great if useSWR could have something like this for conditional data fetching.

[shuding]

Thanks! It makes sense, my current concern is that do we need two ways to do the same thing (not sure about deprecating this existing approach). Maybe we need a transition period.

Perhaps in your internal codebase you can create a util hook on top of SWR to add a skip option for now.

[yash-sharma01]

I totally agree with you. In fact, I've created a wrapper hook that does the work for me.

Answering your point, we can have both approaches simultaneously.

Adding one more option in SwrOptions will make it work.

[VitaliyPotapov]

I use a middleware for that:

/**
 * Middleware to conditionally skip swr hook execution.
 */
export const swrSkip = (skip: unknown = true): Middleware => {
  return (useSWRNext) => {
    return (key, fetcher, config) => {
      return useSWRNext(skip ? null : key, fetcher, config);
    };
  };
};

Usage:

useSWR(path, fetcher, { use: [ swrSkip(true) ] });

[yash-sharma01]

@VitaliyPotapov That's a nice alternative.

I've created a custom hook that fulfills my use case 😄

Sharing a snippet below 👇

export interface ExtendedSWROptions extends Partial<PublicConfiguration> {
  skip?: boolean;
}

export function useSWRFetch<TResData, TErrData = {}, TErrError = {}>(
  fetchKey: string | null,
  swrOptions?: ExtendedSWROptions
) {
  const url = swrOptions?.skip || !fetchKey ? null : fetchKey;

  const { data, error, isLoading, isValidating, mutate } = useSWR(
    url,
    swrOptions
  );

  const isError = error && !isLoading && !isValidating;
  const resData = data as ApiResponse<TResData> | undefined;
  const errData = error as ApiError<TErrData, TErrError> | undefined;

  return {
    isError,
    isLoading,
    isValidating,
    isFetching: isValidating || isLoading,
    revalidate: () => mutate(),
    data: resData?.data,
    error: errData?.response?.data,
    rawError: errData,
    rawResponse: resData,
  };
}

[VitaliyPotapov]

Yes, with custom hook that works nice as well.
We moved with middleware because in our project we already have many places where we pass original SWRConfiguration, so replacing it with kind of ExtendedSWROptions would be a huge change..

[yash-sharma01]

That's a fair point mate. ✌️

[willi-hill]

I believe that this new prop is very beneficial for the lib, because leaving the Null Key we lose access to the current cache data.

With a separate configuration, the hook will be able to return the cache data and still know whether or not to call the fetcher (Whether when requested manually or even in automatic situations such as revalidateOn...)