Custom link component as server component
Unanswered
Californian posted this in #help-forum
CalifornianOP
We have a problem where we have an application that has a custom link component that resolves links based on an
We use links inside client components, which raises a few problems in how we can implement some components.
A few solutions we have tried:
1) Render the
2) Use a context with a rather huge table of the links so that the client can resolve the links.
3) Write a
Solution 1) is kind of tedious and error prone. It's also much harder to read the code since the JSX is split into multiple files.
Solution 2) works at the moment, but we find that we often have a stale context and some links will therefor not work. (Requires us to purge client cache on demand, which we haven't solved).
Solution 3) does not work for us. It creates a separate API call for every link on the current page.
Is there any best practice on solving this?
id prop.We use links inside client components, which raises a few problems in how we can implement some components.
A few solutions we have tried:
1) Render the
<Link/> components server side in a parent (or higher) server component and send them as props to client components.2) Use a context with a rather huge table of the links so that the client can resolve the links.
3) Write a
<Link/> component that looks up on the id, but on the client side.Solution 1) is kind of tedious and error prone. It's also much harder to read the code since the JSX is split into multiple files.
Solution 2) works at the moment, but we find that we often have a stale context and some links will therefor not work. (Requires us to purge client cache on demand, which we haven't solved).
Solution 3) does not work for us. It creates a separate API call for every link on the current page.
Is there any best practice on solving this?
28 Replies
u are still calling the api in a rsc tho
if the data fetched by the id is not that big, u could cache that data with a rsc on the client and look it up in your custom link component
CalifornianOP
Optimally, we would like to combine all requests into one in that case
@Californian Optimally, we would like to combine all requests into one in that case
yeah maybe try the thing i told u above
CalifornianOP
Interesting. Fetch it as rsc into the client?
@Californian Interesting. Fetch it as rsc into the client?
No, u render a custom hook that provides that data
in layout for example
the hook can be accessed by your custom client component
the hook receives the data from rsc
CalifornianOP
Sounds like solution 2 (context)
Aha
A context can decrease perfomance tho, if u have a hook, it will be faster
CalifornianOP
This is great.Thanks!
u can also do that one fetch call with the hook itself (but u loose the caching of nextjs, if u have a external endpoint)
CalifornianOP
Yes, that's my main concern (decrease performance with context)
@Californian Yes, that's my main concern (decrease performance with context)
Most of the time u wont notice it
U could load a huge json file in the background without the user noticing anything
CalifornianOP
I'm also concerned about looking up all the links in that context on navigation. Sounds like we should just wasm a sqlite of the sitemap. Just kidding, the site only has about 20k pages, but still.
CalifornianOP
I will try that. Thanks
Will also need to figure out how to invalidate stale data. We're just now trying transitioning to Next.js with server components and have a few obstacles to tackle. This is a good issue to figure out before we commit 100%
yeah
CalifornianOP
We went for fetching the data in the layout and setting the context based on that data. We use tags to invalidate the data to make sure it doesn't go stale for visitors.
We will test streaming it in in the client to compare performance.
We will test streaming it in in the client to compare performance.
The Link component
use that data to populate the Next Links👍