Skip to content
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

Hydration bug (build only) with components from linked dependency #522

Closed
aeplay opened this issue Dec 6, 2022 · 6 comments
Closed

Hydration bug (build only) with components from linked dependency #522

aeplay opened this issue Dec 6, 2022 · 6 comments
Labels
bug Something isn't working

Comments

@aeplay
Copy link

aeplay commented Dec 6, 2022

I kept running into hydration issues in my production build of a mostly static site based on the with-tailwind template (SSR yes, TS yes). Dev server always works fine.

The only thing that seems special about my setup is that I import some components from a linked dependency in the same monorepo (using "link:../component-lib" syntax in package.json).

When I manually pull in the components so they're just local, the production build hydrates correctly.

I created a minimal reproduction of the whole setup in https://github.com/aeplay/solid-start-linked-hydration

You can toggle between the two scenarios by un/commenting these lines:

https://github.com/aeplay/solid-start-linked-hydration/blob/3049243436f523111fd550b2d0ccec0d196e82cc/app/src/routes/index.tsx#L1-L7

This is what the dev server renders (yarn dev):

Screen Shot 2022-12-06 at 14 26 41 014

This is what happens in the production build (yarn build && yarn start)

Screen Shot 2022-12-06 at 14 26 23 730

As you can visually see, on hydration, it seems to insert a copy of the preceding MiniStory container into the <em> element inside the MiniStorys that contain an <em>. (Before hydration, the server-rendered HTML looks correct)

In my more complex actual app, I also get lots of errors trying to read nextSibling of null, I guess this minimal scenario is a lucky one where hydration actually finds another (albeit wrong) element to attach to.

Since this differs between dev and build and is related to dependencies, I wonder if this is a side-effect of #127 ?

Thank you for your help.

@ryansolid ryansolid added the bug Something isn't working label Dec 22, 2022
@marbemac
Copy link
Contributor

I'm running into something very similar to this as well - @aeplay were you able to find a workaround by any chance?

// basic component in a separate package in our monorepo
export const Box = (p: any) => {
  return <div id="COMP_FROM_LOCAL_PACKAGE" {...p} />;
};

Just taking the solid-start bare boilerplate and wrapping the body content in root.tsx with the Box component imported from the separate monorepo package results in a blank screen when running solid-start start (but works fine with solid-start-dev).

What's rendered on the server (javascript off):

Screenshot 2023-01-12 at 2 25 01 PM

Turning javascript back on and reloading the page - once it picks up on the client, it turns into this:

Screenshot 2023-01-12 at 2 25 57 PM

Weirdly two title tags in head, and obviously all the content was wiped.

This is on solid-start v0.2.11 with the latest start-node adapter (also tried with cloudflare pages adapter, same thing).

@marbemac
Copy link
Contributor

marbemac commented Jan 12, 2023

Hmm - setting dev: true in the vite config causes the issue to disappear, although I'm not sure what implications are for prod build 🤔.

Screenshot 2023-01-12 at 2 41 48 PM


Edit: Passing false to optimizeDeps.disabled also seems to resolve the issue (without having to pass dev: true to the solid plugin. Again, not sure re other side effects / safety of this option though.

@ryansolid
Copy link
Member

There is a lot of awkwardness with optimize deps and not which led us to use a plugin created for SvelteKit to walk through dependencies and find which ones have Solid JSX etc.. I'm gathering link completely is ignored by this walk.

We needed to do this all originally because we needed to set JSX to optimize to dedupe but needed to have the specific files all reject other ESBuild would output React JSX. We now in SolidStart have a Solid ESBuild plugin so ESBuild works fine. Maybe we need to just always package ESBuild Solid with our Vite plugins.

@marbemac
Copy link
Contributor

Yeahh, and in fact optimizeDeps ended up resulting in a separate issue. The shared component lib has solid-js in it's dependencies (same version as the app itself), which perhaps is resulting in multiple solid-js getting included, not quite sure TBH. Digging in a bit more.

Screenshot 2023-01-13 at 3 56 44 PM

@0-don
Copy link

0-don commented Mar 31, 2023

yes having the same issue but with optimizeDeps it works but the bundle size increases drastictly

@ryansolid
Copy link
Member

In setting up for SolidStarts next Beta Phase built on Nitro and Vinxi we are closing all PRs/Issues that will not be merged due to the system changing. If you feel your issue was closed in mistake. Feel free to re-open it after updating/testing against 0.4.x release. Thank you for your patience.

See #1139 for more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants