Define client boundary for vendor component library via config

[stkao05]

It would be great if there is a easy way to specify which vendor component packages are client components. This would allow server components to import vendor client components more easily.

Background

Currently, when you import a client component from a vendor package into your server component, like this:

import * as Popover from '@radix-ui/react-popover';

async function page() {
    return <Popover>...</<Popover>
}

you will encounter the error:

Error when evaluating SSR module /src/pages/index.tsx: failed to import "@radix-ui/react-popover"
|- file:///Users/stevenkao/workspace/waku-learn/node_modules/@radix-ui/react-context/dist/index.mjs:1
import {createContext as $3bkAK$createContext, useMemo as $3bkAK$useMemo, createElement as $3bkAK$createElement, useContext as $3bkAK$useContext} from "react";
        ^^^^^^^^^^^^^

This is because not all vendor component libraries have 'use client' explicitly defined. One solution is to create a wrapper file with 'use client' directive.

// lib/popover.ts

"use client";
export Popover from "@radix-ui/react-popover";

However, it is still not ideal as they require creating additional file for each vendor component.

Proposal

Allow client package defined by config (package.json, or maybe in the future waku.config.json)

{
  clientPackages: ['@radix-ui/react-popover'],
}

[dai-shi]

Thanks for opening up a discussion.
There are a few nuances that we hesitate with the proposal. a) "use client" is controlled by the react library, not waku. b) this is a temporary solution until ecosystem grows. c) just adding "use client" may not solve all the cases (I think only context provider case would make sense. so, it feels very limited.)
Having that said, what would be possible is to run some preprocessors. Essentially, it would be creating a wrapper file automatically.

so, it feels very limited.

What would be recommended it to move more parts to client components while those libraries don't support server components yet. In that sense, doing things behind the scene might confuse the user more.

[stkao05]

Thanks for the fast reply.

What would be recommended it to move more parts to client components while those libraries don't support server components yet.

Not sure if this is desirable solution tho - maybe there are some part that does not need to be in the client component but developer would now need to move them to workaround this issue.

this is a temporary solution until ecosystem grows.

I am curious to hear what you think would be the ideal way in long term.

[stkao05]

ok i see the current recommendation from react.dev doc

If these libraries have been updated to be compatible with React Server Components, then they will already include 'use client' markers of their own, allowing you to use them directly from your Server Components. If a library hasn’t been updated, or if a component needs props like event handlers that can only be specified on the client, you may need to add your own Client Component file in between the third-party Client Component and your Server Component where you’d like to use it.

[dai-shi]

👍