Global link and image components using server components
Unanswered
Orinoco Crocodile posted this in #help-forum
Orinoco CrocodileOP
I am working on upgrading a code base to use the new app router. The project uses a custom component library which is used in other projects, so it needs to have configurable link and image components to support both next/link and next/image in addition to regular anchor and image tags for use outside Next.js.
Today, this is solved by using a global context provider which wraps all other components, where link and image components are provided as props and made available to all child components. As the context API doesn't work with server components inside /app, I am trying to find another solution which doesn't involve providing custom link and image components as props for every component from the library.
Has anyone faced a similar challenge and found a good solution?
Today, this is solved by using a global context provider which wraps all other components, where link and image components are provided as props and made available to all child components. As the context API doesn't work with server components inside /app, I am trying to find another solution which doesn't involve providing custom link and image components as props for every component from the library.
Has anyone faced a similar challenge and found a good solution?
4 Replies
@Orinoco Crocodile I am working on upgrading a code base to use the new app router. The project uses a custom component library which is used in other projects, so it needs to have configurable link and image components to support both next/link and next/image in addition to regular anchor and image tags for use outside Next.js.
Today, this is solved by using a global context provider which wraps all other components, where link and image components are provided as props and made available to all child components. As the context API doesn't work with server components inside /app, I am trying to find another solution which doesn't involve providing custom link and image components as props for every component from the library.
Has anyone faced a similar challenge and found a good solution?
<Link> and <Image> are both client components, so you don't need to worry about having to use server components; it's not bad to use client componentsso just render them in a client component wrapper that consumes the context provider if you want
Orinoco CrocodileOP
Thanks for replying! The issue with that approach, if I understand you correctly, is that:
1. The library provides page builder modules which uses both links and images. If I were to wrap these modules, all of them would be client components, instead of just the images and links, making most of the content client components. A lot of other components, like the footer (which comes from the library), also use links and images inside them, forcing the whole component to be a client component instead of just the links.
2. I would have to wrap all link and image components, which are used in a lot of places.
Or am I missing something?
The end goal is to use server components as much as possible, while using client components for the smallest parts possible to send the least amount of JS to the client, while still keeping as much as possible of the ergonomic developer experience the current solution provides.
1. The library provides page builder modules which uses both links and images. If I were to wrap these modules, all of them would be client components, instead of just the images and links, making most of the content client components. A lot of other components, like the footer (which comes from the library), also use links and images inside them, forcing the whole component to be a client component instead of just the links.
2. I would have to wrap all link and image components, which are used in a lot of places.
Or am I missing something?
The end goal is to use server components as much as possible, while using client components for the smallest parts possible to send the least amount of JS to the client, while still keeping as much as possible of the ergonomic developer experience the current solution provides.
For point 1:
You can use this pattern just fine
function Footer() {
console.log("I’m still a server component")
return <CustomLink />
}
For point 2: yes nothing wrong with that
You can use this pattern just fine
function Footer() {
console.log("I’m still a server component")
return <CustomLink />
}
For point 2: yes nothing wrong with that