-
Notifications
You must be signed in to change notification settings - Fork 47.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Hydration fails in Next.js with server actions actions custom tags #27286
Labels
Status: Unconfirmed
A potential issue that we haven't yet confirmed as a bug
Comments
mritzerfeld
added
the
Status: Unconfirmed
A potential issue that we haven't yet confirmed as a bug
label
Aug 26, 2023
1 task
gnoff
added a commit
that referenced
this issue
Oct 12, 2023
…ementPropertySupport` (#27511) The `enableCustomElementPropertySupport` flag changes React's handling of custom elements in a way that is more useful that just treating every prop as an attribute. However when server rendering we have no choice but to serialize props as attributes. When this flag is on and React supports more prop types on the client like functions and objects the server implementation needs to be a bit more naunced in how it renders these components. With this flag on `false`, function, and object props are omitted entirely and `true` is normalized to `""`. There was a bug however in the implementation which caused children more complex than a single string to be omitted because it matched the object type filter. This change reorganizes the code a bit to put these filters in the default prop handline case, leaving children, style, and innerHTML to be handled via normal logic. fixes: #27286
@mritzerfeld when Next.js updates to an upcoming Canary release you should be able to verify this is fixed |
github-actions bot
pushed a commit
that referenced
this issue
Oct 12, 2023
…ementPropertySupport` (#27511) The `enableCustomElementPropertySupport` flag changes React's handling of custom elements in a way that is more useful that just treating every prop as an attribute. However when server rendering we have no choice but to serialize props as attributes. When this flag is on and React supports more prop types on the client like functions and objects the server implementation needs to be a bit more naunced in how it renders these components. With this flag on `false`, function, and object props are omitted entirely and `true` is normalized to `""`. There was a bug however in the implementation which caused children more complex than a single string to be omitted because it matched the object type filter. This change reorganizes the code a bit to put these filters in the default prop handline case, leaving children, style, and innerHTML to be handled via normal logic. fixes: #27286 DiffTrain build for [bb77852](bb77852)
jerrydev0927
added a commit
to jerrydev0927/react
that referenced
this issue
Jan 5, 2024
…ementPropertySupport` (#27511) The `enableCustomElementPropertySupport` flag changes React's handling of custom elements in a way that is more useful that just treating every prop as an attribute. However when server rendering we have no choice but to serialize props as attributes. When this flag is on and React supports more prop types on the client like functions and objects the server implementation needs to be a bit more naunced in how it renders these components. With this flag on `false`, function, and object props are omitted entirely and `true` is normalized to `""`. There was a bug however in the implementation which caused children more complex than a single string to be omitted because it matched the object type filter. This change reorganizes the code a bit to put these filters in the default prop handline case, leaving children, style, and innerHTML to be handled via normal logic. fixes: facebook/react#27286 DiffTrain build for [bb778528d1ca22b44dad832f0258aaa4c0e6d4a4](facebook/react@bb77852)
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this issue
Apr 15, 2024
…ementPropertySupport` (facebook#27511) The `enableCustomElementPropertySupport` flag changes React's handling of custom elements in a way that is more useful that just treating every prop as an attribute. However when server rendering we have no choice but to serialize props as attributes. When this flag is on and React supports more prop types on the client like functions and objects the server implementation needs to be a bit more naunced in how it renders these components. With this flag on `false`, function, and object props are omitted entirely and `true` is normalized to `""`. There was a bug however in the implementation which caused children more complex than a single string to be omitted because it matched the object type filter. This change reorganizes the code a bit to put these filters in the default prop handline case, leaving children, style, and innerHTML to be handled via normal logic. fixes: facebook#27286
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm currently testing the experimental server actions feature in Next.js. Once this feature is enabled Next.js uses React's experimental build. This however results in hydration failed error messages when using custom HTML tags with a dash like
my-tag
in JSX. The server response does not include any output for this tag and its children. Replacing the custom tag with a regular tag like<div>
works completely fine.I previously reported this issue at vercel/next.js#51141 where they suspect this to be an issue within React itself.
React version: Experimental
Steps To Reproduce
<my-tag>
Link to code example:
https://github.com/mritzerfeld/next-server-action-with-custom-tag
The current behavior
Server-generated contents with custom HTML tags do no produce any output for such.
The expected behavior
Server-generated contents within custom HTML tags to be included in server response, as using Next without server actions or with regular HTML tags.
The text was updated successfully, but these errors were encountered: