Seeking Advice: App Router and SWR/React Query Usage – Best Practices and Recommendations?
Answered
Yellow-throated Warbler posted this in #help-forum
Yellow-throated WarblerOP
Hello everyone!
I'd like to inquire about the general sentiment regarding the utilization of libraries such as SWR / React Query in Next.js App Router applications. While I'm aware that it's possible to create async components and fetch data directly on the server side, our team is accustomed to using SWR / React Query and would like to persist with these libraries.
Is this still considered acceptable, or is it no longer recommended?
This is particularly relevant given that libraries like SWR provide convenient methods for refreshing data on demand, as demonstrated in the following code snippet:
I'm still learning about how best to handle such scenarios with App Router. Any insights or recommendations on this matter would be greatly appreciated!
I'd like to inquire about the general sentiment regarding the utilization of libraries such as SWR / React Query in Next.js App Router applications. While I'm aware that it's possible to create async components and fetch data directly on the server side, our team is accustomed to using SWR / React Query and would like to persist with these libraries.
Is this still considered acceptable, or is it no longer recommended?
This is particularly relevant given that libraries like SWR provide convenient methods for refreshing data on demand, as demonstrated in the following code snippet:
// Example of using SWR to refresh data on demand
const { data, error, mutate } = useSWR('api/data', fetchDataFunction);
// Trigger a manual refresh
const handleRefresh = () => {
mutate();
};I'm still learning about how best to handle such scenarios with App Router. Any insights or recommendations on this matter would be greatly appreciated!
Answered by fuma
With SWR/RQ, it’s client side data-fetching used by traditional web applications, which is not same as server side fetching.
Both have their own benefits, you should leverage them for a full-powered application. You may use server components for blog posts and only do client side fetching for dashboard
Both have their own benefits, you should leverage them for a full-powered application. You may use server components for blog posts and only do client side fetching for dashboard
4 Replies
With SWR/RQ, it’s client side data-fetching used by traditional web applications, which is not same as server side fetching.
Both have their own benefits, you should leverage them for a full-powered application. You may use server components for blog posts and only do client side fetching for dashboard
Both have their own benefits, you should leverage them for a full-powered application. You may use server components for blog posts and only do client side fetching for dashboard
Answer
In my opinion, any queries that involves complicated revalidations and caching, shouldn’t use server components. The
router.refresh isn’t made for such a purpose@fuma With SWR/RQ, it’s client side data-fetching used by traditional web applications, which is not same as server side fetching.
Both have their own benefits, you should leverage them for a full-powered application. You may use server components for blog posts and only do client side fetching for dashboard
Yellow-throated WarblerOP
Thank you for your response! My team primarily builds dashboard/CMS apps for enterprise use, so based on your answer I trust SWR remains a relevant tool for our development needs.
@fuma In my opinion, any queries that involves complicated revalidations and caching, shouldn’t use server components. The `router.refresh` isn’t made for such a purpose
Yellow-throated WarblerOP
That makes total sense. My team is having trouble coming up with proof of concept for such scenario. It's almost like fighting with the framework itself lol.