Fetch Data with or without TanStack Query?
Unanswered
nahuelluca posted this in #help-forum
Hi everyone , i was investigate about fetching data. I was try it with TanStack query but i have a question is performance, its better than only use server actions and Fetch API?
I mean, for use TanStack Query i create a prefetch 'prefetchQuery' and then in a client component get data with 'useQuery', it is better than get data in my react server component and maping that?
I mean, for use TanStack Query i create a prefetch 'prefetchQuery' and then in a client component get data with 'useQuery', it is better than get data in my react server component and maping that?
10 Replies
@nahuelluca Hi everyone , i was investigate about fetching data. I was try it with TanStack query but i have a question is performance, its better than only use server actions and Fetch API?
I mean, for use TanStack Query i create a prefetch 'prefetchQuery' and then in a client component get data with 'useQuery', it is better than get data in my react server component and maping that?
Britannia Petite
Go with server side data fetching, would be auto cached using next.js and if you need mutations use server actions
Netherland Dwarf
Hi @Britannia Petite ,
thanks for your anwser.
I just migrate the solution from react query to entirely server side data fetching following Next docs.
I have few concerns about this approach, my project have lots of complex form and totally serve for ERP.
1. I need to call lots of api in server side. And pass props to client side.
I tried with caching everything about the
- selection data for form
- pagination data for table.
I use the query params for caching that.
So:
a. A table data have many query params like current_page, total_per_page, filter by conditions
=> It leads me hard to control everything.
Example in a screen I have 3 table pagination.
Then I need to create lots of current_page_1, current_page_2, current_page_3
2. Should I cache everything about get requests?
3. Any best practices for preventing pass props to client component
Thanks
thanks for your anwser.
I just migrate the solution from react query to entirely server side data fetching following Next docs.
I have few concerns about this approach, my project have lots of complex form and totally serve for ERP.
1. I need to call lots of api in server side. And pass props to client side.
I tried with caching everything about the
- selection data for form
- pagination data for table.
I use the query params for caching that.
So:
a. A table data have many query params like current_page, total_per_page, filter by conditions
=> It leads me hard to control everything.
Example in a screen I have 3 table pagination.
Then I need to create lots of current_page_1, current_page_2, current_page_3
2. Should I cache everything about get requests?
3. Any best practices for preventing pass props to client component
Thanks
Netherland Dwarf
Example
Britannia Petite
I think that you wont be able to cache dynamic url..
"Any best practices for preventing pass props to client component" what do you mean ?
passing fetched data from a server component to a client component is not a bad practice, this is the way.
passing fetched data from a server component to a client component is not a bad practice, this is the way.
IMO you should just try to avoid deep nested prop drilling..
Netherland Dwarf
1. I think that you wont be able to cache dynamic url..
You can see in my sample code.
In the promise all.
If the params did not change. Then I will get cache from memoized request.
But by this way. It leads me store params to query params.
The issue I mentioned above. I need to recognize which's one params belong to what api
2.
You mean that I need to avoid separate the client components?
But in this case this is the ERP project. If I dont do that. Lots of logic will be held in a same file
=> Conflicting between the coding convention and Next SSR
You can see in my sample code.
In the promise all.
If the params did not change. Then I will get cache from memoized request.
But by this way. It leads me store params to query params.
The issue I mentioned above. I need to recognize which's one params belong to what api
2.
You mean that I need to avoid separate the client components?
But in this case this is the ERP project. If I dont do that. Lots of logic will be held in a same file
=> Conflicting between the coding convention and Next SSR
@Netherland Dwarf 1. I think that you wont be able to cache dynamic url..
You can see in my sample code.
In the promise all.
If the params did not change. Then I will get cache from memoized request.
But by this way. It leads me store params to query params.
The issue I mentioned above. I need to recognize which's one params belong to what api
2.
You mean that I need to avoid separate the client components?
But in this case this is the ERP project. If I dont do that. Lots of logic will be held in a same file
=> Conflicting between the coding convention and Next SSR
Britannia Petite
1. maybe you can prefix your query params to identify which api to fetch.. ?
2. I don't understand the question ?..
2. I don't understand the question ?..
Netherland Dwarf
1. maybe you can prefix your query params to identify which api to fetch.. ?
=> correctly
2. I mean that the client side is trying to separate the component following single responsibility
props ={ticketLogging1,ticketLogging2,ticketLogging3, ticketassigment1, ticketassignment2, ticketrelationship1 }
<Client props>
<Header />
<Content props>
<TicketLogging only some props/>
<TicketAssignment only some props/>
<TicketRelationship only some props/>
</Content>
</Client>
=> correctly
2. I mean that the client side is trying to separate the component following single responsibility
props ={ticketLogging1,ticketLogging2,ticketLogging3, ticketassigment1, ticketassignment2, ticketrelationship1 }
<Client props>
<Header />
<Content props>
<TicketLogging only some props/>
<TicketAssignment only some props/>
<TicketRelationship only some props/>
</Content>
</Client>