SWR is a simple no-nonsense way to manage fetches and mutations optimistically. I've used this in a couple of my projects. 2.0 looks like a major QoL improvement.

I think the big difference between react-query and its competitors like SWR is typescript support.

React-query has proper sum types for its hook’s return value

> I think the big difference between react-query and its competitors like SWR is typescript support.

Redux-toolkit-query has a fantastic typescript support.

I just rig up a wrapper around swr to make it have the types I want. Only takes a few lines of code.

How is it different than…?

const { data } = useSWR<MyDataType>(“/my/data”)

With `useSWR` the return type is

    export interface SWRResponse<Data = any, Error = any> {
      /**
       * The returned data of the fetcher function.
       */
      data: Data | undefined
      /**
       * The error object thrown by the fetcher function.
       */
      error: Error | undefined
      mutate: KeyedMutator<Data>
      isValidating: boolean
      isLoading: boolean
    }
 

https://github.com/vercel/swr/blob/14956a840ac9b75fe321bf846...

so if I check `isLoading` in my component then typescript isn't able to narrow/refine the type to something more specific since it isn't a sum type.

While with react-query, it's a proper sum type that can be differentiated by checking `isLoading`.

The type is actually quite long so here's just a bit

    export type QueryObserverResult<TData = unknown, TError = unknown> =
      | QueryObserverIdleResult<TData, TError>
      | QueryObserverLoadingErrorResult<TData, TError>
      | QueryObserverLoadingResult<TData, TError>
      | QueryObserverRefetchErrorResult<TData, TError>
      | QueryObserverSuccessResult<TData, TError>


    export interface QueryObserverLoadingResult<TData = unknown, TError = unknown>
      extends QueryObserverBaseResult<TData, TError> {
      data: undefined
      error: null
      isError: false
      isIdle: false
      isLoading: true
      isLoadingError: false
      isRefetchError: false
      isSuccess: false
      status: 'loading'
    }

https://github.com/TanStack/query/blob/9b21609350d9ad41faf5c...

The key point in the type above is `isLoading: true` and `data: undefined`, which means if I check `isLoading === true`, then typescript knows the data is not available.

SWR doesn't provide these guarantees.

Thank you for the explanation!

Better SSR/SSG support would have been appreciated. The way I like the most is with prepass and extracting a state from the client making me not care at all what I do in my components. "It just works" which is kind of what I expect from a Vercel product

Thanks for the feedback. In the future we will be focusing on closing that gap. Some research is still going on and with Next.js 13's server components and server-side data fetching primitives, I believe there will be a great experience to use SWR and Next.js to have all the scenarios covered.

That's a slightly high standing-wave ratio; they need to tune their antenna better...

This is exactly what I thought when I saw that title. And I was just measuring the SWR of my roof-mounted omni antenna.

Is SWR so well-known that no definition is needed at the beginning of the article? I have no idea what it stands for or whether it's an open-source library or some vercel-specific optimization.

EDIT: Nevermind, the entire subdomain is about SWR, you can just go to the homepage.

Nice. We’ve been happy users of SWR. It just works and gets out if your way.

Glad to hear it! Open to any feedback for things can improve, as well.

I remember hearing that SWR lacks a lot of the functionality that makes React Query great. Does anyone care to compare the two?

What's the future of SWR with the Next.js 13 App directory? Delba mentioned the new App functionality will replace the need for SWR in Next.js apps.

We answered that in the blog post: https://swr.vercel.app/blog/swr-v2#the-future--thank-you

> With the new release of Next.js 13, we see a lot of exciting new things as well as paradigm shifts in the React ecosystem: React Server Components, streaming SSR, async components, and the use hook. Many of them are related to data-fetching, and some of them have overlapping use cases with SWR. > > However, the goal of the SWR project remains the same. We want it to be a drop-in library that is lightweight, framework agnostic, and a little bit opinionated (i.e. revalidate upon focus). Instead of trying to be a standard solution, we want to focus on innovations that make the UX better. In the meantime, we are also doing research on how to improve SWR with these new abilities of React.

Has nothing to do with Standing Wave Ratios. Darn.

Can you cancel requests using SWR?