You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hydrating a component on the client produces the following stack trace:
TypeError: Cannot read properties of null (reading '__H')
at d2 (index.js:2386:15)
at s2 (index.js:2393:12)
at h2 (index.js:2390:18)
at Section (index.js:2513:45)
at Section (index.js:2346:16)
at index.js:2589:11
at sonataHydrateComponents (index.js:2592:7)
at index.js:2597:1
More specifically, I am encountering this error in my project's Section component, when it tries to call the useState hook on the client. The component is rendered first on the server with preact-render-to-string, then sent over to the browser for hydration. Many other people have encountered a similar problem and I've linked their issues above, but none of the solutions have worked for me, mainly because:
They are having issues with Next.js (which I am not using), or
They are having issues with their bundlers duplicating the module (which is not happening as I looked at the bundled source code closely and didn't see any duplication).
If you want to experience this issue for yourself, clone the project, invoke npm run dev/pnpm dev in your terminal, then navigate to localhost:8081. The source code that's bundled for the client will be available in /dist/static/index.js. You will notice that there is no code duplication anywhere (cited as the root cause of many of the issues I linked above).
So far, a common trait is that the library is simply bundled within an ESM context, mixed with server-side rendering. The error seems to reproduce across multiple bundlers (e.g. I use esbuild, Next.js uses swc, other projects used Webpack). I wouldn't like the solution to be "ship your entire client code unbundled" or "use CJS/disable ESM", since that has been mentioned as "solutions" in some of the previous issues.
Note: The function calling hydrate is an async context, but I've tried it with and without being in an async context and the error is the same, so it is unrelated.
Edit: Esbuild bundling analysis reveals there are no duplicate modules, in case you don't want to look at the bundled source code yourself.
The text was updated successfully, but these errors were encountered:
Fixed it myself. This was a problem with manually invoking the component in my hydrating code instead of letting preact do it's thing. Basically, Component(...) replaced with <Component .../>.
Related issues
#3635
#4176
#2690
#3393
vercel/next.js#39030
Description
Hydrating a component on the client produces the following stack trace:
More specifically, I am encountering this error in my project's
Section
component, when it tries to call theuseState
hook on the client. The component is rendered first on the server withpreact-render-to-string
, then sent over to the browser for hydration. Many other people have encountered a similar problem and I've linked their issues above, but none of the solutions have worked for me, mainly because:If you want to experience this issue for yourself, clone the project, invoke
npm run dev
/pnpm dev
in your terminal, then navigate tolocalhost:8081
. The source code that's bundled for the client will be available in/dist/static/index.js
. You will notice that there is no code duplication anywhere (cited as the root cause of many of the issues I linked above).So far, a common trait is that the library is simply bundled within an ESM context, mixed with server-side rendering. The error seems to reproduce across multiple bundlers (e.g. I use
esbuild
, Next.js usesswc
, other projects used Webpack). I wouldn't like the solution to be "ship your entire client code unbundled" or "use CJS/disable ESM", since that has been mentioned as "solutions" in some of the previous issues.Note: The function calling
hydrate
is an async context, but I've tried it with and without being in anasync
context and the error is the same, so it is unrelated.Edit: Esbuild bundling analysis reveals there are no duplicate modules, in case you don't want to look at the bundled source code yourself.
The text was updated successfully, but these errors were encountered: