Id love to see the pros and cons of react query and useswr. I’ve always thought that react query was like useswr++ . The optimistic updates looks like useswr is closing in on what react query already offers. It’s just missing a caching mechanism I believe.
@@jackn In react query you have lots of control over cache - polling/auto refetching, invalidation of stale data, refetch on mount/tab focus… prob some more that i missed. Do you know if swr has similar or additional capabilities?
You can do optimistic updates with react query. I don't really see the benefits of going SWR2.0 over React-Query. DX, syntax, etc, look even way cleaner with React-Query imo
The killer feature of react query in NextJs is being able to use it server side and rehydrate client side. This gives you all the cache benefits of react query but using SSR. I’d gladly switch to SWR if vercel offered a more “official” implementation for this inside of Next.
It’s super easy to do with SWR. The thing is, SWR is trying to not opinionate this process. I took over tRPC-swr maintenance this week. SWR’s unopinionated architecture for ssr allows us to do some pretty cool stuff. We are implementing an API similar to react-query for ssr, but we can go in many different directions. Like supporting Next 13’s new appdir
Thank you, Matt, this was extremely informative and useful! I have to say, I have not come across a single thing made by Vercel that was anything short of excellent for developer experience. I've been working on a project that uses SWR lately and so far I really like the simplicity, though it had some things that I missed from react-query, like keeping previous data while revalidating, but this update solves that as well.
Although tanstack query is the king of these libraries, I always considered useSWR a far more leaner and simple approach to the whole affair - do one thing and do it well with a simple but not simplistic approach, hence a very good DX. Now with useSWRMutation the gap closes a lot - good job Vercel!
I would say that SWR is pretty good if all you really want to do is data fetching. React query is better for just asynchronous processes in general tho. In other words, what useSWR does is accomplish just a single part of what tanstack aims to do. Both actually have different goals, and it's really up to the user which they prefer/need.
Don't sweat it. You buy in to more stuff than you think by trying to avoid it. Don't think of it as "single entity" but that you rely on smaller libraries, just like you would do with other libraries. If anything you depend on now gets deprecated you either keep them as they already work, or you move onto something else when you're missing something or need to upgrade something else that it doesn't work with. You can never avoid buying into others code as long as you use other's code. Those are tradeoffs you make as an engineer per project, business and goal.
Tbh most environments have a pretty singular aproach to solving problems. It's here in the frontend ecosystem where you have like a thousand ways to fetch data or to store state.
@@samu350 Name one "environment" with such a condition. There's not a single way to do multi-threading, I/O, state management, networking, caching, data models, architecture, and I could go on. None of which has anything to do with frontend.
Yeah, you're right, I'm just saying other career paths don't have as many paths to take as frontend work. I see most backend devs focusing on learning AWS, .NET or Spring. Or game developers focusing on Unity with C#, or C++ with Unreal. Then you see frontend devs doing WordPress, or maybe React, or Angular, or maybe a no-code platform, or maybe picking between Tailwind, Bootstrap, or maybe using TypeScript vs not using it? I understand none of that tackles the very specific problems you say, but I don't see as many options being pushed to other paths every year as frontend does. All tech influencers shill new stuff like zod, or htmx, or Astro, or Qwik.js, or whatever is coming out this year. I don't think this is bad at all, but it can very easily confuse new devs. Then you see a new game developer just straight up just learning Unity.
@@samu350 You're only seing a small slice of those fields, then. Game development is a very broad term. Whether you work in audio engineering, physics, rendering and tooling, to game design there are many paths just within that field. Even within AWS, which still requires a ton of infrastructure to run efficiently, there are dedicated people who knows intrinsic parts (networking, data storage, you name it). React, Tailwind, whatever other tech are just building blocks to build on top of, each with their own tradeoffs. This is, again, not unique to "frontend".
It's the same for styled-jsx which is a lame copy of emotion/styled-components. And yet it goes packaged with every NextJS app (not really bundled in prod, but still takes some space in dev).
But then you're using redux. Unless you're in a legacy situation there's no good reason to be using redux anymore (and there are better libraries with WAY less boilerplate if you want redux-like patterns). Redux is like angular or jquery, It was important at a particular time in history, introduced and popularized ideas, but things have evolved
has anyone built a sort of library or hook that leverages SWR or React Query and Firestore? I'm particularly looking to solve deeply nested firestore listeners
I have a slight and possibly naive concern. At what point do developers using the NextJS ecosystem feel they need to use Vercel for hosting and thus get locked into an ecosystem? This is somewhat of a moot point in some ways - so many developers are locked into various ecosystems for convenience - AWS for example. Sure, we _could_ opt out of these incredible time saving and performance enabling services... I'll get my coat ... but whilst I grab it from the coat hook, I do have some niggling concerns about exactly _where_ we are putting our apps and data ... 🤔
That's great and all, but unless it's either like turbopack where it does the competitor's job a whole lot better, or it reaches feature parity with tanstack, there's no reason for me to swap yet. Another downside to this is migration issues as I highly doubt this is going to be the last version of SWR while tanstack, even if it does get new versions, it's pretty much near feature complete so I won't have as much of a worry for migration.
Big fan of swr, still use it. With nextjs 13 app directory, I didn't think swr had a role? I thought Vercel made it clear most data fetching should be done in server components (not client). Not sure where swr fits in next 13 app directory. I miss it though, it is so much more snappy than server components data fetching.
It definitely has a role. SSR is fine, but remember the request only runs once. Next has no way to target a specific RSC to get its data once more, they’re working on it, but I don’t think we’ll have it for a 2-3 months. How I use it with Next 13: Layouts will prefetch data into SWRConfig, I keep the RSC’s that don’t need data updated and then use SWR on all other components.
Always find swr api design especially naming conventions are weird, they way they’d use the word mutation is so confusing, I’d choose react query over this any day
I have really mixed feelings about optimistic updates. Should you make it known to the user that the request is being verified while you show them the new UI, in the form of the loading icon? In which case, they would wait for the request to complete anyway, and are they really benefitting from the UI update? If you don't notify them that the request is loading, you run the risk of the user leaving the page thinking that their action was successful, when in reality it might not be.
there are critical data you dont want to be optimistic. imagine sending money, payment, crypto, emails, etc. anything that locks or enables user to do next should avoid optimistic updates. cms, shopping cart, profile edits, etc seems ok to revert back to previous successful state
I'm trying to understand useSWR(), when you search for videos or information are very focused on explanations based on a list of data, ok everything makes perfect sense. But I'm trying to understand how I use something as simple as a login screen, I type email and password and click to enter... In this case I would be using useSWR() when I click the enter button. So I'll be executing a useSWR() inside a function and in the body of the component how do I execute useSWR() in this way example const fnSubmit = () => { useSWR('url', fetcher) } The FACT useSWR(), being a hook I can't execute as above, how could I do it? the fetcher could be like this -> const fetcher = async () => { const _body = { email: login.data.email, password: login.data.password } const _param = { method: 'POST', headers: new Headers({ 'Content-Type': 'application/json' }), body: JSON.stringify(_body) } }
it does, but you have to handle it yourself and it's not fully type safe, at least not as far as I have seen, but tbh it's just better to only use optimistic updates in very simple use cases.
TanStack Query is better architected over SWR, IMO. SWR couples your data fetching logic inside your React component, while TanStack Query allows you to supply your own fetching code. The separation of concerns is much better in TanStack Query.
Using that means you'll also be using redux toolkit.. Yikes!! No thanks but I ain't a fan of unnecessary boilerplate when easier and cognitive friendly alternatives and patterns for state management exist🤝
YAFF: Yet Another Fetching Framework I'll stick to Tan Stack, thanks. Vercel wants to be the Google of development and, personally, I don't like that. It's very totalitarian of them.
it's too much going on lately, my brain feels overstimulated...
True
it is almost like react query
watched this video 4 months ago and understood nothing
now everything is clear!
I really like how SWR 2.0 does optimistic updates more than Reaxt-Query, it's very simple. for React-query you need to write so much more code
I'm seeing that now. For one thing, AFAIK so far, I don't need to create the Providers and import 4-5 things to start. This1⃣ works like a simple 🪝.
Id love to see the pros and cons of react query and useswr. I’ve always thought that react query was like useswr++ . The optimistic updates looks like useswr is closing in on what react query already offers. It’s just missing a caching mechanism I believe.
SWR is playing catch up. Atm react-query is just better.
For simple apps, SWR is perfect. For anything complicated, react-query is king.
SWR automatically caches based on the URL path (first argument of useSWR hook)
@@jackn In react query you have lots of control over cache - polling/auto refetching, invalidation of stale data, refetch on mount/tab focus… prob some more that i missed. Do you know if swr has similar or additional capabilities?
You can do optimistic updates with react query. I don't really see the benefits of going SWR2.0 over React-Query. DX, syntax, etc, look even way cleaner with React-Query imo
The killer feature of react query in NextJs is being able to use it server side and rehydrate client side. This gives you all the cache benefits of react query but using SSR. I’d gladly switch to SWR if vercel offered a more “official” implementation for this inside of Next.
It’s super easy to do with SWR. The thing is, SWR is trying to not opinionate this process.
I took over tRPC-swr maintenance this week. SWR’s unopinionated architecture for ssr allows us to do some pretty cool stuff. We are implementing an API similar to react-query for ssr, but we can go in many different directions. Like supporting Next 13’s new appdir
These recent uploads have been 🔥
Awesome, thanks pal - really enjoying these news-style updates.
Thank you, Matt, this was extremely informative and useful! I have to say, I have not come across a single thing made by Vercel that was anything short of excellent for developer experience.
I've been working on a project that uses SWR lately and so far I really like the simplicity, though it had some things that I missed from react-query, like keeping previous data while revalidating, but this update solves that as well.
Although tanstack query is the king of these libraries, I always considered useSWR a far more leaner and simple approach to the whole affair - do one thing and do it well with a simple but not simplistic approach, hence a very good DX. Now with useSWRMutation the gap closes a lot - good job Vercel!
I would say that SWR is pretty good if all you really want to do is data fetching. React query is better for just asynchronous processes in general tho. In other words, what useSWR does is accomplish just a single part of what tanstack aims to do. Both actually have different goals, and it's really up to the user which they prefer/need.
I worry about overusing too much technology from a single company and in the eventuality it's required to port somewhere else, its nearly impossible.
Don't sweat it. You buy in to more stuff than you think by trying to avoid it. Don't think of it as "single entity" but that you rely on smaller libraries, just like you would do with other libraries. If anything you depend on now gets deprecated you either keep them as they already work, or you move onto something else when you're missing something or need to upgrade something else that it doesn't work with.
You can never avoid buying into others code as long as you use other's code. Those are tradeoffs you make as an engineer per project, business and goal.
Tbh most environments have a pretty singular aproach to solving problems.
It's here in the frontend ecosystem where you have like a thousand ways to fetch data or to store state.
@@samu350 Name one "environment" with such a condition. There's not a single way to do multi-threading, I/O, state management, networking, caching, data models, architecture, and I could go on. None of which has anything to do with frontend.
Yeah, you're right, I'm just saying other career paths don't have as many paths to take as frontend work.
I see most backend devs focusing on learning AWS, .NET or Spring.
Or game developers focusing on Unity with C#, or C++ with Unreal.
Then you see frontend devs doing WordPress, or maybe React, or Angular, or maybe a no-code platform, or maybe picking between Tailwind, Bootstrap, or maybe using TypeScript vs not using it?
I understand none of that tackles the very specific problems you say, but I don't see as many options being pushed to other paths every year as frontend does.
All tech influencers shill new stuff like zod, or htmx, or Astro, or Qwik.js, or whatever is coming out this year.
I don't think this is bad at all, but it can very easily confuse new devs. Then you see a new game developer just straight up just learning Unity.
@@samu350 You're only seing a small slice of those fields, then. Game development is a very broad term. Whether you work in audio engineering, physics, rendering and tooling, to game design there are many paths just within that field.
Even within AWS, which still requires a ton of infrastructure to run efficiently, there are dedicated people who knows intrinsic parts (networking, data storage, you name it).
React, Tailwind, whatever other tech are just building blocks to build on top of, each with their own tradeoffs. This is, again, not unique to "frontend".
The title suggests Vercel benefits from us choosing SWR, but the video didn’t cover that. Do they?
Vercel's mission is to try and make their open source tools so good that you buy into their ecosystem. So, yes!
I struggle to identify a single reason why would Vercel not just use react-query since SWR is essentially a copy of react-query
maybe integration with next.js (in the future it would be sth build in to fetch data?)
react-query does more but at 3x the min+gzip size.
Well useSWR does only one thing but it does really well, really easily and in a very *very* simple way.
bc they create it when react-query was not that popular, also SWR is more simple and less heavy
It's the same for styled-jsx which is a lame copy of emotion/styled-components. And yet it goes packaged with every NextJS app (not really bundled in prod, but still takes some space in dev).
Love your videos Matt!
So if you are using Next.js, you should use SWR instead of React-Query ?
do i still need an extra client state manager for UI or SWR would be enough?
still walmart tanstack-query 😅
Magnetar also does this, including a caching mechanism :O
It Just lacks the marketing for now to make it more mainstream 😅
link?
0:58 you meant to say, "High Latency"... if it low, then it's fast... 😊
Redux RTK query already has these features 😉
But then you're using redux. Unless you're in a legacy situation there's no good reason to be using redux anymore (and there are better libraries with WAY less boilerplate if you want redux-like patterns). Redux is like angular or jquery, It was important at a particular time in history, introduced and popularized ideas, but things have evolved
does react query have preloading? if not, it should.
how about redux rtk query
react query have this features since v3, there are no way SWR will replace react query
I remember Meteor JS having similar thing back in the day.
has anyone built a sort of library or hook that leverages SWR or React Query and Firestore? I'm particularly looking to solve deeply nested firestore listeners
Do you advice me to switch to use SWR for pagination or stay using react/query ?
Both are great!
I have a slight and possibly naive concern. At what point do developers using the NextJS ecosystem feel they need to use Vercel for hosting and thus get locked into an ecosystem?
This is somewhat of a moot point in some ways - so many developers are locked into various ecosystems for convenience - AWS for example.
Sure, we _could_ opt out of these incredible time saving and performance enabling services...
I'll get my coat ... but whilst I grab it from the coat hook, I do have some niggling concerns about exactly _where_ we are putting our apps and data ... 🤔
That's great and all, but unless it's either like turbopack where it does the competitor's job a whole lot better, or it reaches feature parity with tanstack, there's no reason for me to swap yet. Another downside to this is migration issues as I highly doubt this is going to be the last version of SWR while tanstack, even if it does get new versions, it's pretty much near feature complete so I won't have as much of a worry for migration.
Big fan of swr, still use it.
With nextjs 13 app directory, I didn't think swr had a role? I thought Vercel made it clear most data fetching should be done in server components (not client). Not sure where swr fits in next 13 app directory.
I miss it though, it is so much more snappy than server components data fetching.
It definitely has a role. SSR is fine, but remember the request only runs once. Next has no way to target a specific RSC to get its data once more, they’re working on it, but I don’t think we’ll have it for a 2-3 months. How I use it with Next 13:
Layouts will prefetch data into SWRConfig, I keep the RSC’s that don’t need data updated and then use SWR on all other components.
Always find swr api design especially naming conventions are weird, they way they’d use the word mutation is so confusing, I’d choose react query over this any day
Can I use useSWR with typescript?
Yes!
to use it with typeScript I modify the fetcher right?
that it returns a promise of some type (for example a promise of todo)
@0:59 its really high latency not low latency I think
Yes! Misspoke, whoops
Is this the next 13 data mutation story ?
I have really mixed feelings about optimistic updates. Should you make it known to the user that the request is being verified while you show them the new UI, in the form of the loading icon? In which case, they would wait for the request to complete anyway, and are they really benefitting from the UI update? If you don't notify them that the request is loading, you run the risk of the user leaving the page thinking that their action was successful, when in reality it might not be.
there are critical data you dont want to be optimistic. imagine sending money, payment, crypto, emails, etc. anything that locks or enables user to do next should avoid optimistic updates. cms, shopping cart, profile edits, etc seems ok to revert back to previous successful state
I feel like SWR is just stuck playing catch-up with React Query, sadly.
nice try Vercel, but I still see react-query as a better designed code to solve the problem.
I'm trying to understand useSWR(), when you search for videos or information are very focused on explanations based on a list of data, ok everything makes perfect sense. But I'm trying to understand how I use something as simple as a login screen, I type email and password and click to enter... In this case I would be using useSWR() when I click the enter button. So I'll be executing a useSWR() inside a function and in the body of the component how do I execute useSWR() in this way example const fnSubmit = () => {
useSWR('url', fetcher)
}
The FACT useSWR(), being a hook I can't execute as above, how could I do it?
the fetcher could be like this ->
const fetcher = async () => {
const _body = { email: login.data.email, password: login.data.password }
const _param = {
method: 'POST',
headers: new Headers({ 'Content-Type': 'application/json' }),
body: JSON.stringify(_body)
}
}
The rollback thing is pretty cool, not sure if React Query has something like this
it does, but you have to handle it yourself and it's not fully type safe, at least not as far as I have seen, but tbh it's just better to only use optimistic updates in very simple use cases.
TanStack Query is better architected over SWR, IMO.
SWR couples your data fetching logic inside your React component, while TanStack Query allows you to supply your own fetching code.
The separation of concerns is much better in TanStack Query.
What do you mean? SWR lets you use a custom fetcher that is not coupled to any React code.
@@benkogan1579 He's just making shit up lol 😂
the white theme is a sin
Honestly guys, just use RTK query.
All problems solved.
Using that means you'll also be using redux toolkit.. Yikes!!
No thanks but I ain't a fan of unnecessary boilerplate when easier and cognitive friendly alternatives and patterns for state management exist🤝
not as good as rq
I've been doing this with sagas long time ago.
YAFF: Yet Another Fetching Framework
I'll stick to Tan Stack, thanks. Vercel wants to be the Google of development and, personally, I don't like that. It's very totalitarian of them.