How to handle data fetching in three components and searchParams?
Answered
Sloth bear posted this in #help-forum
Sloth bearOP
Hi!
There are three components, each with its own data fetch using prisma ORM.
Two of them use different search parameters, while one doesn’t use any.
What’s the best approach to implement them so that data fetching and loading states (Suspense) are only triggered in the components that actually need them (i.e., only when a specific search param changes)?
Should they be client components and fetch data via server actions...?
The issue: If they are server components, all requests are sent every time.
There are three components, each with its own data fetch using prisma ORM.
Two of them use different search parameters, while one doesn’t use any.
What’s the best approach to implement them so that data fetching and loading states (Suspense) are only triggered in the components that actually need them (i.e., only when a specific search param changes)?
Should they be client components and fetch data via server actions...?
The issue: If they are server components, all requests are sent every time.
Answered by B33fb0n3
You have two options:
1. Stay on server (searchParams)
-> To display specific loading animations for the specific parts, you can use suspense boundaries that are triggered by your fetching functions. Other parts of your app might receive data faster than others and like that the specific parts "stream in". Problem: when searchParams change you make a new server request, to change your page.
2. Transfer to client components.
-> use clientside fetching for specific parts of your app to reload only these part, when your states changing. The problem from "1." is solved like that and you wont have waterfalls, as each one is it's own part. When using react query for example you can get used of the
Of course you can also use a combination of it, like fetching initial data on the server, pass it to the client and the client handle future data requests
--- Edit
For instant searchParam changes without a new server request, read this: https://nextjs-forum.com/post/1344249673640185887#message-1344307543924805733
1. Stay on server (searchParams)
-> To display specific loading animations for the specific parts, you can use suspense boundaries that are triggered by your fetching functions. Other parts of your app might receive data faster than others and like that the specific parts "stream in". Problem: when searchParams change you make a new server request, to change your page.
2. Transfer to client components.
-> use clientside fetching for specific parts of your app to reload only these part, when your states changing. The problem from "1." is solved like that and you wont have waterfalls, as each one is it's own part. When using react query for example you can get used of the
useSuspenseQuery so it triggers your suspense boundary as well. Like that you dont need to change that much.Of course you can also use a combination of it, like fetching initial data on the server, pass it to the client and the client handle future data requests
--- Edit
For instant searchParam changes without a new server request, read this: https://nextjs-forum.com/post/1344249673640185887#message-1344307543924805733
12 Replies
@Sloth bear Hi!
There are three components, each with its own data fetch using prisma ORM.
Two of them use different search parameters, while one doesn’t use any.
What’s the best approach to implement them so that data fetching and loading states (Suspense) are only triggered in the components that actually need them (i.e., only when a specific search param changes)?
Should they be client components and fetch data via server actions...?
The issue: If they are server components, all requests are sent every time.
You have two options:
1. Stay on server (searchParams)
-> To display specific loading animations for the specific parts, you can use suspense boundaries that are triggered by your fetching functions. Other parts of your app might receive data faster than others and like that the specific parts "stream in". Problem: when searchParams change you make a new server request, to change your page.
2. Transfer to client components.
-> use clientside fetching for specific parts of your app to reload only these part, when your states changing. The problem from "1." is solved like that and you wont have waterfalls, as each one is it's own part. When using react query for example you can get used of the
Of course you can also use a combination of it, like fetching initial data on the server, pass it to the client and the client handle future data requests
--- Edit
For instant searchParam changes without a new server request, read this: https://nextjs-forum.com/post/1344249673640185887#message-1344307543924805733
1. Stay on server (searchParams)
-> To display specific loading animations for the specific parts, you can use suspense boundaries that are triggered by your fetching functions. Other parts of your app might receive data faster than others and like that the specific parts "stream in". Problem: when searchParams change you make a new server request, to change your page.
2. Transfer to client components.
-> use clientside fetching for specific parts of your app to reload only these part, when your states changing. The problem from "1." is solved like that and you wont have waterfalls, as each one is it's own part. When using react query for example you can get used of the
useSuspenseQuery so it triggers your suspense boundary as well. Like that you dont need to change that much.Of course you can also use a combination of it, like fetching initial data on the server, pass it to the client and the client handle future data requests
--- Edit
For instant searchParam changes without a new server request, read this: https://nextjs-forum.com/post/1344249673640185887#message-1344307543924805733
Answer
Sloth bearOP
@B33fb0n3 I tried with two components
page.tsx - home page, I don't use props.searchParams anymore
GlobalInfo.tsx
Questionnaires.tsx
I use next links with search params to build pagination and when I click on any pagination link => it waits for 10s and then it gives me a new page with updated url => client side fetching starts for 1s
I can wrap big request in a suspense with something like key={JSON.stringify(searchParams)} but it will execute this big request each time, In my mind I want to fully isolate these blocks, is it possible?
page.tsx - home page, I don't use props.searchParams anymore
<>
<GlobalInfo />
<Questionnaires />
</>GlobalInfo.tsx
const info = getInfo(); // imagine this is 10s request
....
return ....JSXQuestionnaires.tsx
const [loading, setLoading] = useState(true);
const [data, setData] = useState([]);
const searchParams = useSearchParams();
const page = searchParams.get('page');
useEffect(() => {
const fetchData = async () => {
try {
setLoading(true);
const data = await getData(page); //imagine this is 1s
setData(data.user);
setLoading(false);
} catch (err) {
setLoading(false);
}
};
fetchData();
}, [page]);I use next links with search params to build pagination and when I click on any pagination link => it waits for 10s and then it gives me a new page with updated url => client side fetching starts for 1s
I can wrap big request in a suspense with something like key={JSON.stringify(searchParams)} but it will execute this big request each time, In my mind I want to fully isolate these blocks, is it possible?
@B33fb0n3 yea, that should be possible with the ways, that I showed you 👍
Sloth bearOP
changing searchParams with next/link triggers full page/route rerender => anyway nextjs executes all requests once again
isn't it?
isn't it?
@B33fb0n3 that's correct. That#s the problem, that I mentioned
Sloth bearOP
in your second option do you mean I need to manage page number within state instead of searchParams?
@Sloth bear in your second option do you mean I need to manage page number within state instead of searchParams?
yea, the second approach is using client components only. So the page number would be saved inside a state on the client.
The third option is a possible combination of both. If you want to have the combination, make sure to take a look at nuqs: https://nuqs.47ng.com/
The third option is a possible combination of both. If you want to have the combination, make sure to take a look at nuqs: https://nuqs.47ng.com/
@B33fb0n3 yea, the second approach is using client components only. So the page number would be saved inside a state on the client.
The third option is a possible combination of both. If you want to have the combination, make sure to take a look at nuqs: https://nuqs.47ng.com/
Sloth bearOP
so this is something like [Shallow Routing](https://nextjs.org/docs/pages/building-your-application/routing/linking-and-navigating#shallow-routing) ?
I used it within page router a long time ago, but didn't find anything for 'app'
there was something, but I'm not sure it exists now
we just use nuqs instead of next's tools for managing search params and next "doesn't know" that it needs to refetch everything, am I right?
I used it within page router a long time ago, but didn't find anything for 'app'
there was something, but I'm not sure it exists now
experimental: {
windowHistorySupport: true,
},we just use nuqs instead of next's tools for managing search params and next "doesn't know" that it needs to refetch everything, am I right?
and this way we can keep state between page refreshes
@Sloth bear so this is something like [Shallow Routing](https://nextjs.org/docs/pages/building-your-application/routing/linking-and-navigating#shallow-routing) ?
I used it within page router a long time ago, but didn't find anything for 'app'
there was something, but I'm not sure it exists now
experimental: {
windowHistorySupport: true,
},
we just use nuqs instead of next's tools for managing search params and next "doesn't know" that it needs to refetch everything, am I right?
yea, we change the searchParams only on the client without making a new request to the nextjs server. In the documentation you can read about it here ([read more](https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating#using-the-native-history-api))
@B33fb0n3 yea, we change the searchParams only on the client without making a new request to the nextjs server. In the documentation you can read about it here ([read more](https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating#using-the-native-history-api))
Sloth bearOP
awesome, I like this solution, thank you so much! Will try to implement
happy to help