Web Component Complex Values not working as expected on latest canary about next.js HOT 3 OPEN

Thanks! I think I have a more comprehensive response to this issue at large in the React issue: facebook/react#29037 (comment)

I think that your example code in case 1 if fleshed out could be very valuable documentation for other people using the new custom elements in React support in next.js

from next.js.

Note that the second web component (one that uses dynamic loading and ssr: false) does get all complex values set via the web component's properties and new automatic event listener adding/removal.

This has the desired outcome, right?

The current implementation of custom elements in react is only at step 1 as I wrote in my doc, so it is best to work around server rendering and hydration of custom elements as you did in the second web component because react can't know how to apply props to a not-yet-defined custom element.

This is the first feedback about server rendering and hydration I've gotten since developing the improved custom elements in react feature years ago, so this is a good signal that we should consider implementing step 2 in my doc to make it easier to do the workaround that you made in the second web component.

(I may be mis-interpreting what's going on here, I don't understand next.js very well and I didn't dive in very deep to the codesandbox)

from next.js.

All good!
Here's the tl;dr:
Yes, I do think getting farther along with the RFC's goals would be a valuable pre-requisite for accounting for different Next.js client+server permutations. The workaround certainly makes sense, and your callout that the current react implementation isn't a full implementation of your original RFC plans is helpful. I was under the impression that react 19's web component support would be closer to what was documented in the RFC. Happy to help in any way I can here (including potential PRs, where appropriate), and also would love to have some visibility/information on the plans/timelines of fully implementing the RFC goals, assuming that's feasible. I do have some concerns about not resolving facebook/react#29037 before React 19 moves from RC to official, since that would be a breaking change (not the end of the world, but may lead to some unfortunate friction).

Here's a more detailed breakdown of the situation. With respect to different client+server permutations on Next.js, we've got 3 relevant cases:

1. No rendering, partial hydration, etc. etc. occurs on the server

Example:

const MyReactComponent = dynamic(() => import('./MyReactComponent'), {
  loading: () => <p>Loading...</p>,
  ssr: false, // This is what ensures the component will be instantiated *entirely* on the client side
});

// ...

const MyContainerComponent = () => {
  // ...
  return <MyReactComponent/>; // Using the component, including on an RSC
};

2. Partial hydration occurs on the server, followed by client side updates
   • This is any component module flagged with 'use client';
3. full on RSC/server-side only rendered components
   • No rendering et al. on the client.

Ideally, imo, we want all 3 permutations to work smoothly with web components for relevant use cases.

(1) should only be necessary if a web component author does not e.g. provide appropriate shims for Web APIs defined on globalThis to ensure their module does not explode when running on e.g. node (like my team does on our Media Chrome web component based library). There are other reasons, unrelated to web components, that authors may want to dynamically load, but it should not be a pre-requisite for using web components on Next.js. Currently, this is the only permutation that works reliably/predictably with Next.JS.

(2) is the most likely desired permutation for most web component + Next.js use cases. The problem with the current behavior is that something will end up being set as an attribute on the partial hydration server side, but never get set as a property on the second pass on the client side, including the cases I described in facebook/react#29037. This effectively makes partial hydration unpredictable and likely to be avoided for (almost?) all React + web component usage. I also think this is a reason to ensure things like objects are never set as attributes (per my discussion in the linked react issue).

(3) is also useful, but likely only for a subset of web components (e.g. custom container web components, display-only web components, and the like, all only if they can be useful with only attributes).

from next.js.