Fix location of SolidJS pre-hydration code

[hippotastic]

Changes

• Makes the SolidJS pre-hydration code actually run before hydration.
• Before this fix, we were inlining a <script> block after each component, no matter if it was supposed to get hydrated or not.
• Fixes Solid integration renders script tags after each component instance, even non-hydrated ones #3132.

Testing

Tested locally on Windows 10 in dev mode, build, and SSR using Netlify adapter.

Docs

This is not a visible change, just a code fix/refactor.

[changeset-bot]

🦋 Changeset detected

Latest commit: 448cf57

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@astrojs/solid-js	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[hippotastic]

Not sure what the issue with that failing CI test is. All tests pass locally for me (except the deno test, which always fails, even without my changes).

[natemoo-re]

Looks like a clean fix! I'm going to rerun the tests, might just be a flakey issue on Windows.

[ryansolid]

It's the weirdest thing but I can't place it. But the difference between the 0.1.1 and 0.1.2 of the Solid integration, which I believe is only this PR, consistently takes longer to server render. I don't see how this PR could be responsible but it is super consistent. No other packages changed.. just that. In my brutal Hackernews test I consistently see ~.7 second different FCP/LCP times.

If anyone has any ideas.

EDIT:

I have some ideas now. And it's completely annoying. It's incidental admittedly. It's that having all those script tags seemed to have interrupted the document getting it to paint part of the page earlier recording faster FCP and LCPs because it paints in chunks. Swapping to this more efficient way has it paint the whole page together.

I'm going to ignore this but it explains a lot.

Before:

After:

Look at where the FCP and LCP are in relation to the purple layout events (this is where it's doing the majority of the work)

[FredKSchott]

Reminder that we should really bundle all of those scripts together into a single one on the page

[hippotastic]

Reminder that we should really bundle all of those scripts together into a single one on the page

I agree, @FredKSchott, and this is exactly what my PR did. Surprisingly, the previous implementation that rendered tons of inline scripts had better FCP and LCP measurements in Ryan's extreme test case vs. mine that just uses a single script for the hydration.

Could you share the code of your Hackernews test so we could have a look, @ryansolid? Maybe we can find a solution to your discovery that the browser starts painting later when the document is not broken up into pieces through all the inline scripts anymore. At least I'd love to have a quick look.

[ryansolid]

I think @FredKSchott is also referring to Astro's own scripts which you don't see in my screen shot but there are like 1000 of them after the document load event.

As for the painting thing, every other (non-streaming) implementation works the way this has been upgraded to. I'm not really concerned. Here's the repo, but I haven't updated, I was working on the edge branch but I needed to hack some things for it to work so haven't pushed. The behavior is equally applicable to the non-edge version: https://github.com/ryansolid/astro-solid-hackernews/tree/main