[feat]: Mark renderer with "use client" to be used in Server Components

[zynth666]

A clear and concise description of what the feature is

Currently, if I want to use this renderer in a Server Component I would have to create a wrapper with the "use client" directive. This feature aims for seamless usability within the next.js framework, especially with the use of the app router.

Why should this feature be included?

It makes it easier for consumers of this package since you don't have to create a wrapping boundary.

Please provide an example for how this would work

See: https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#advice-for-library-authors

[joshuaellis]

Let me guess, it can't be used as an RSC because it uses React.Context?

[zynth666]

You're goddamn right :D

[joshuaellis]

🧠 @remidej we might need to add a plugin to pack-up because it might strip out the directive. I'm not sure and this would need to be tested before publishing stable 🌞

[zynth666]

This is my current workaround for anyone wondering.

"use client";

import { BlocksRenderer } from "@strapi/blocks-react-renderer";

type BlocksRendererProps = Parameters<typeof BlocksRenderer>[0];

export default function RichText(props: BlocksRendererProps) {
  return <BlocksRenderer content={props.content} blocks={props.blocks} />;
}

[remidej]

This makes me wonder if we should remove the use of React context altogether. Prop drilling is annoying, but I think opting out of server components may be worse. Especially since rich text is probably mostly used in static pages, with a requirement to have good SEO etc.

[joshuaellis]

This makes me wonder if we should remove the use of React context altogether. Prop drilling is annoying, but I think opting out of server components may be worse. Especially since rich text is probably mostly used in static pages, with a requirement to have good SEO etc.

Server components doesn't mean it's not server-side rendered @remidej

[remidej]

@joshuaellis you mean that it's not binary and you can do interleaving between server and client, right? But shouldn't we still try to have as much as possible on the server when possible? at least just to have less client side JS code?

[joshuaellis]

Yeah pretty much, afaik you can still SSR context // state etc. and then it should be hydrated, I'm not sure if next forces you to use RSC to SSR though.

I think weigh up how long the refactoring would take and what it would look like — could composition replace the need for it? Is it us being "preemptive" of needs?

If it won't take long to remove the context then great. We can also probably get it added to this list once we're done – https://github.com/reactwg/server-components/discussions/6