Comments (3)
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:
- 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
};
- Partial hydration occurs on the server, followed by client side updates
- This is any component module flagged with
'use client';
- This is any component module flagged with
- 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.
Related Issues (20)
- MSW Turbopack fails to import HOT 6
- ReferenceError: window is not defined... in client component? HOT 7
- Next 14 is not working properly in docker on windows with bun, but normal at local terminal HOT 6
- Sourcemaps are not loaded in index pages with a dynamic route level deeper than one
- SVG with icons not updating after change HOT 6
- [backport request] Backport fix of an already-fixed bug of next-swc HOT 7
- FileList is not defined on client component HOT 3
- Memory Leak with Image Optimization in Next.js Docker Environment
- When tried to deploy latest canary to vercel -- Error: Invariant: prefetchDataRoute can't be set without PPR HOT 3
- Revalidate does not work on Vercel Deployment only HOT 1
- Buffer polyfill not work on ios lower then 14 HOT 1
- Buffer polyfill not work on ios lower then 14 HOT 9
- Custom page extension + own sitemap/robots route bug - route source code returned instead of Response HOT 2
- Router cache does not revalidate HOT 4
- Importing svg's using svgr/webpack no longer works in the latest canary release when using ppr (error: Cannot read properties of undefined (reading 'stack')) HOT 2
- Unexpected token Ident("tr") HOT 1
- outputFileTracing increases export build time by 1.5-2x HOT 1
- In iPhone Safari browser, quickly clicking the refresh button will cause the page to always display the content from loading.tsx HOT 1
- Turbopack error on edge runtime(middleware): `Error [TypeError]: _react.default.createContext is not a function` HOT 12
- Invalid hook call error
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from next.js.