React Server Components - fetching
Unanswered
Argentine ant posted this in #help-forum
Argentine antOP
Hello!
We have been moving over our client components to server components. An example, one of our dashboards now has 6 server components that use server actions to fetch data etc, and also have client components inside of them to search, paginate etc using seachParams. One issue, for example, is changing a search query value from a client component, updating the URL - and this is refetching the data in all of the server components. Is there a better way to handle this, or does this sound like a job for client components instead?
Thanks
We have been moving over our client components to server components. An example, one of our dashboards now has 6 server components that use server actions to fetch data etc, and also have client components inside of them to search, paginate etc using seachParams. One issue, for example, is changing a search query value from a client component, updating the URL - and this is refetching the data in all of the server components. Is there a better way to handle this, or does this sound like a job for client components instead?
Thanks
15 Replies
Thrianta
Are you using some sort of ISR or revalidation logic? You can force nextjs to cache your page or parts of it. This can be revalidated by time eg after 5 seconds. Or programmatically, eg. a user triggers a server action or api request and you use
revalidatePath or revalidateTag. This revalidation is appiled by route segment config, or inside fetch requests. You can even look into the experimental unstable_cache from next/cache for caching things like orm calls. Lmk@Thrianta Are you using some sort of ISR or revalidation logic? You can force nextjs to cache your page or parts of it. This can be revalidated by time eg after 5 seconds. Or programmatically, eg. a user triggers a server action or api request and you use `revalidatePath` or `revalidateTag`. This revalidation is appiled by route segment config, or inside `fetch` requests. You can even look into the experimental unstable_cache from next/cache for caching things like orm calls. Lmk
Argentine antOP
hey thanks for your time!
So to put it into perspective:
1) page under
2) a bunch of server components that use server actions to directly fetch from the database
So say we have 10+ of these server components to make up our dashboard, and we have a search component somewhere that changes the searchParams - is there any simple way to only get the server component that relies on that data to 'refetch' just for that component?
So to put it into perspective:
1) page under
app/dashboard/page2) a bunch of server components that use server actions to directly fetch from the database
So say we have 10+ of these server components to make up our dashboard, and we have a search component somewhere that changes the searchParams - is there any simple way to only get the server component that relies on that data to 'refetch' just for that component?
Argentine antOP
considering just making them client components and just using the initial data
Thrianta
Yea maybe use client components. Can you share any code for what the server components look like? Are you prop-drilling from your page.tsx (which receives searchParams as a prop) to the server components that need the searchParams?
Also side note is that server actions (async functions in a
"use server" file) shouldn't really be used for fetching data. They make requests with the POST header and cannot be cached (i believe*). Instead i make a queries.tsx file with import "server-only" at the top and put queries in there. I use server-only to make sure they can only run on the server side@Thrianta Also side note is that server actions (async functions in a `"use server"` file) shouldn't really be used for fetching data. They make requests with the POST header and cannot be cached (i believe*). Instead i make a `queries.tsx` file with `import "server-only"` at the top and put queries in there. I use server-only to make sure they can only run on the server side
Argentine antOP
just a side note on this - calling a 'server action' from a server component doesn't fetch in any different way to a normal async function
Thrianta
Nice. I have wondered about that before. 👍🏼
@Thrianta Nice. I have wondered about that before. 👍🏼
Argentine antOP
i think the main problem i'm having currently is using server components is a totally different way of thinking - I'd reach a hurdle like having to create a component with some sensitive data that shouldn't be in a URL and i'd rethink everything - when something like this just needs to go into a client component
but i'd end up thinking 'okay, i need to turn this whole component into a client component' when in actual fact that's not necessary - just the inputs i don't want in the URL plus the button that submits - since we can pull everything else handled in server components into the client component
@Thrianta Nice. I have wondered about that before. 👍🏼
Argentine antOP
I've just had a thought - so, if we have some data that we don't want to be put into a link / can be shared - couldn't we technically just use context in these components? that way, they can reside in their individual server components, and just the interactive parts use context - then in some other client component, can access all of the values?
just a shower thought 😂
Thrianta
Yea that might be the play. Lmk if it was what you were looking for
Argentine antOP
if anyone else reads this, one thing to note about using context:
if it's a dynamic component i.e. you have multiple components in a list, and you want to have server components elsewhere selectable for example and form part of your form / data, you can set the ID or something of the row you're editing in the URL, and then listen to that change to clear the context data, so it's fresh for every component
if it's a dynamic component i.e. you have multiple components in a list, and you want to have server components elsewhere selectable for example and form part of your form / data, you can set the ID or something of the row you're editing in the URL, and then listen to that change to clear the context data, so it's fresh for every component
this would be the only reason i'd personally use the context method, as a way to keep server component functionality as part of a form but not have it all in one client component (and not having to expose it over a URL)
Argentine antOP
tl;dr - don't make components too complex, if you need user input in a form, just build a server component that passes in the data for the form, and then use a client component to render