SWR 2.0 – React Hooks for Data Fetching(swr.vercel.app)
swr.vercel.app
SWR 2.0 – React Hooks for Data Fetching
https://swr.vercel.app/blog/swr-v2
10 comments
I remember hearing that SWR lacks a lot of the functionality that makes React Query great. Does anyone care to compare the two?
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
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.
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”)
const { data } = useSWR<MyDataType>(“/my/data”)
With `useSWR` the return type is
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
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.
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!
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.
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.
> 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.
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.
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.
Has nothing to do with Standing Wave Ratios. Darn.
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.
EDIT: Nevermind, the entire subdomain is about SWR, you can just go to the homepage.
Can you cancel requests using SWR?