SolidStart Beta 2 #1052

ryansolid · 2023-09-06T19:43:05Z

ryansolid
Sep 6, 2023
Maintainer

There has been a lot of anticipation about when SolidStart can get out of Beta and move to 1.0. But unfortunately we are not ready yet. I think that is clear from the nature of bugs and issues we are facing. While there are some happy paths (node, UNIX, SSR) a lot of what Start does is pretty buggy. We've also learned a lot over the process on what we did well as APIs and what has failed. We also want to design a platform that keeps us open to the future.

I apologize for the time it has taken to post another update. The last one was over 8 months ago. Even then the path for what we needed to do was clear, it just wasn't obvious how we were going to achieve it. There were some fundamental issues with how Start was setup and large amount of work required to fix it. We've done a lot of exploration over the last several months that now I feel comfortable starting the discussion about Starts future.

And that starts with Beta 2. A second beta run that applies what we've learned. Why mark it like so? Well there will be some breaking changes. Not necessarily the largest for hobby apps, but we are changing how SolidStart deploys. We also need to make some other API level changes. This is why I want to include everyone in the discussion. Some decisions are pretty certain but many have a lot of details that are still being worked out and could use your feedback.

Summary of Changes

So what does a second Beta look like high level:

1. Rebase to Nitro's adapters and Vinxi

We want to offload the work on the adapter level and Nitro(powers Nuxt and Analog) can handle that for us. @nksaraf has been building a universal bundler/fs router on top of it which handles a lot of the specific wiring. This means that SolidStart stops maintaining adapters and our Vite Plugin basically becomes just configuration into this more generalized system. This will mean support for things like per page pre-renders, and properly supported CSR-only mode. It will mean proper support of code extraction like server functions, ie.. they will work regardless of if imported on the server, so behind lazy components, in CSR-only mode etc. And one of the messiest parts of SolidStart (the vite plugins) basically goes away.

Nitro
vinxi

2. Merge the Start CLI with the Solid CLI community project

SolidStart's CLI is sort of powerful but also tends to break. Long term I'd like our examples in here just to replace the degit templates. So we're going to combine efforts with the Solid CLI and make Start just a target for it. This will be much more powerful and allow for more things in the future. We should also re-alias create-solid. In combination with the Nitro changes above long term SolidStart doesn't really even need to be a mono repo (except for docs). Long term the docs effort could even be merged with other docs efforts.

3. Update the entry point

As much as I like how we have this Isomorphic Root it has been problematic for things like CSR mode. When considering that and things like Islands routing in the future I think we should start from an app.tsx and have the document part of the server entry. app.tsx will look pretty much exactly as it would in our other Vite templates or like CRA. Just starts from the mount point.

Something like this (this may not be the final API here):

// app.tsx
import { A, Router, Routes } from "@solidjs/router";
import { MetaProvider } from "@solidjs/meta";
import { FileRoutes } from "@solidjs/start";
import { Suspense } from "solid-js";

export default function App() {
  return (
    <MetaProvider>
      <Router>
         <A href="/">Index</A>
         <A href="/about">About</A>
         <Suspense>
           <Routes>
             <FileRoutes />
           </Routes>
         </Suspense>
      </Router>
    </MetaProvider>
  )
}

// entry-server.tsx
import { createHandler, StartServer } from "@solidjs/start/server";

function Document(props) {
  return (
    <html lang="en">
      <head>
        <link rel="icon" href="/favicon.ico" />
        {props.assets}
      </head>
      <body>
        {props.children
        {props.scripts}
      </body>
    </html>
  );
}

export default createHandler((context) => <StartServer context={context} document={Document} />);

This will keep things clean for the different modes of operation without worry about leaking side effects. It will also let us have a natural split for the top-level layout for Islands routing.

Part of this change will involve removing many of the capital letter Components that belong only in the root. Things like <Html>, <Head> or <Body>. Instead you can use lowercase versions. This will reduce API surface area and unnecessary import statements and align better with other changes.

4. Stop aliasing other libraries through Start

My intention is to move solid-start to @solidjs/start and in so we won't be aliasing other packages. @solidjs/router or @solidjs/meta would be referenced directly. This leaves very few imports from @solidjs/start and leaves a very clear sense of responsibility. This also lets start be independent of improvements to those libraries other than version bumps. With changes to routing it should be possible for even the router of SolidStart to be replaceable so this is how we reach our goal.

5. Update the router

I want to move createRouteData and createRouteAction back into the router package and deprecate their createServer____$ equivalents. If you wish to use a server function just use a server function. This will allow us to make clearer, better APIs than trying to use some sort of first argument convention. It is also more explicit and doesn't give it special treatment while expanding the API surface unnecessarily. To accomplish this, Solid itself will need a standard interface for accessing server context/request so every third-party library can access it. In so we should be able to pull the Context Providers like the router into user/application space.

There are other API changes for the router that will need consideration when trying to universalize for Islands. Things like using props.children instead of <Outlet /> and revisiting the upper case vs lowercase design of anchors. Also re-evaluate where @solidjs/meta belongs. As part of the router we may be able to do more ahead of time.

Also we should update the fileSystem routing convention. Instead of routeData we should export a routeConfig that can pass through other options to the route other than just data, like prerender, or matchFilters etc... Basically any data we'd send to the route config other than the component we could put there.

6. Better Middleware setup

We want Middleware to work across modes and different entries even if those entries are deployed to different locations. By making the fileSystem router more configurable we should be able to split apart where things are deployed and will need smarter wiring of middleware. To start that might just be a optional middleware.ts for global middleware. But I want to talk with the community to understand what the best patterns are.

7. Revisit `server$` vs `use server` and `island$` vs `use client`

These mechanisms won't be owned by SolidStart but will be configurable by it. The conventions of decorator vs directive has consequence and I'd like to find a consistent convention when considering all the different permutations.

Moving Forward

Work towards this has begun on the vinxi branch. It is not ready to use yet but we are seeing good progress. I want to share this now so that you all know what to expect and can be part of the process. Bugs and missing features (not backported in the router for example) aside the new branch is ~1200 LoC over 30 files vs the ~10,700 LoC over 150 files of current Start. That's the ballpark of difference this is going to make.

For existing projects other than things that tap into middleware/request it is mostly going to just be a matter of updating imports and changing the config and root of the project. It may be easiest to copy your routes and non-start related folders into a fresh project. I have not dedicated effort for migration as we are still in beta, but I would welcome thoughts here.

Ultimately the goal is to expedite our 1.0 release and that is why we are introducing a new version with breaking changes. We've applied what we've learned to build a more solid project.

danieltroger · 2023-09-07T08:22:31Z

danieltroger
Sep 7, 2023

Epic! I've been trying solid start on a couple of projects (overall it's great) and many of my issues with it look like they're being addressed.

Here's some feedback that might be helpful that wasn't addressed, just quickly jotted down.

I'm not sure if "6. Better Middleware setup" includes this but one other area where I really struggled (this might be a docs thing) was setting a cookie on the server with a unique id for each client and getting that cookie value on the client. I tried various things for 1.5 hours before giving up.

And lastly, I've had lots of issues with the router. I reported one which got fixed and there's also another one which I didn't report.
I wrote down this line (probably where I thought the bug was) https://github.com/solidjs/solid-router/blob/d0695a715912db2480e082d03e5f0533a8b87e2d/src/routing.ts#L397 in case it turns out solid start is not a dead project and issues get fixed, so I don't waste my time writing a report and this is what I wrote in the workaround code:

Solid-start's useIsRouting is buggy, we do our own instead.
The issue with it is that it claims to have finished routing before it has updated location.href (called the History API). This results in our components taking and pushing the wrong URL. // clarification from now: we sometimes add query params as soon as one navigates to a new page, this was where I had issues

Furthermore I got really annoyed by your efforts of waiting for something before the router actually commits to updating the page. I think the idea is to wait for the next page to have loaded or something before showing it, but I don't need that since either the pages are sufficiently small that I don't want any lazy loading of them or I want to show placeholders/skeletons which appear instantly (so navigation should complete instantly) and then I take care of lazy loading my big things myself.

While other people might want it different, the biggest problem with solid's approach detailed above is the following:
When going back or forwards (popstate event fired) it's not guaranteed that the new components provided to the router (when not using file based routing) are IN THE DOM BEFORE THE LAST popstate EVENT HAS BEEN HANDLED. This can break the browser native scroll restoration.

From countless hours of debugging when implementing an SDK where scroll restoration is absolutely crucial and deciding to rely on browser native scroll restoration I'm telling you this very-little-known and documented requirement for browser native scroll restoration to work: the DOM must have been updated to the target page, at least the height of the target page (or greater) before the last popstate event has been handled in the event queue. Because after that is when the browser attempts to restore the scroll position, and if the page then is shorter than it should be, the browser can't restore the correct scroll position.

I can't speak for other users, but for me "instant routing" where native scroll restoration just works is far more important than whatever fancy features you have to delay navigation that I don't use.

3 replies

ryansolid Sep 7, 2023
Maintainer Author

I think I may be misunderstanding the ask. If there is async data loading of any sort how could the elements be in the DOM synchronously by the end of handling the popstate event. The event trigger is what tells us to start rendering the next page so I don't quite understand how anything async could be present.

I imagine this has to do with the Transition feature that holds the page (similar to browser holding) until the content is present. It seems like React had a similar problem: facebook/react#26025

I'm not quite clear on what their solution is because admittedly being able to hold navigation was one of the main if not the main use case for Transitions. In any case thanks for bringing this to my attention. This seems to be something we inherited from taking an approach similar to React.

danieltroger Sep 8, 2023

Glad I could help!

If there is async data loading of any sort how could the elements be in the DOM synchronously by the end of handling the popstate event.
The event trigger is what tells us to start rendering the next page so I don't quite understand how anything async could be present.

It can't, unless https://developer.chrome.com/docs/web-platform/navigation-api/ lands in all browsers and you start using it (IIRC it had a thing where you could tell the browser when to do the scroll restoration).

But for my use cases, that's where placeholders/skeletons come in: they look like the page and can be made of the same height as the content. One can put them into the DOM synchronously and then replace them with the content once the data loading has finished. This way both scroll restoration works and things feel snappier for the user.

I imagine this has to do with the Transition feature that holds the page (similar to browser holding) until the content is present.

Yep, that's probably exactly it. I would really appreciate if there'd be a way to turn that off or otherwise get solid to guarantee that my components are in the DOM before the end of handling the popstate event, if I don't use lazy importing or the Transition feature. If you augment the browser behavior flawlessly that's also fine I guess, I'm maybe needlessly sceptical of attempting that.

It seems like React had a similar problem: facebook/react#26025

Oh wow, very interesting. Given that they seem to have solved the implicit popstate condition given by the browsers for scroll restoration, the issues we had with next.js and scroll restoration are probably not due to react but due to next.js. In next.js, it's also not guaranteed that things are in the DOM synchronously after all popstate events have been handled. Our workaround is to hook into the next router and then add 20k px of paddingBottom to <body> during the navigations, but I'd love solid even more if there was a better way :D

BTW, I'm the guy who got server side rendered solid components to work in next.js with SSR, my colleague was on some conference where you were and he said you were interested to have a look at it. Lmk if you want me to explain more, I'd love to show you around. But you can also reverse engineer it:
If you set up a next.js app and import { TextPlaceholder } from "@depict-ai/react-ui/latest"; and then add a <TextPlaceholder> to your page, it should get SSR:d and have reactive properties, and it's actually the TextPlaceholder component from @depict-ai/ui which is a solid-js component.

phiberber Dec 20, 2023

I'd love to see a blog post from you about your experience with mixing Next and Solid, you're a very good writer.

F4b4n · 2023-09-07T08:45:45Z

F4b4n
Sep 7, 2023

I'm here only to express my gratitude towards everyone who contributed to Solid and SolidStart in any way.
You are the ones who are shaping the future of the web. Thank you for your contributions, you are amazing! 🙌

2 replies

danieltroger Sep 7, 2023

Agreed! I think the web could benefit a lot from people starting to use solidJS more

riolly Sep 7, 2023

Thank you for always thinking about the long term and for the best of the community @ryansolid

caseybaggz · 2023-09-07T14:12:04Z

caseybaggz
Sep 7, 2023

Thanks for this update and all the hard work @ryansolid ! My project is getting pretty large but the only real issues I've found so far that wasn't able to work around while keeping the code clean and scalable have been:

1. Nested routing with multiple `Outlet` don't work

This means that in a scenario where the root starts with FileRoutes and a group of children that has a templated root which uses Outlet that also contains another group that follows the same pattern doesn't work for the nested children.

Example:

- routes
     - [group]
        - (group).tsx (outlet)
        - settings.tsx (outlet)
        - [settings]
          - (settings).tsx <-- never reads the local `routeData` only gets it from `[group]`

2. `client-entry` ships unused JS

In my lighthouse reports, Solid-Start is doing amazing outside of delivering unused JS in the prod build. I'm using lazy and and other techniques but still cannot figure out how to do this - but assumed it would already be managed via the solid Vite plugin.

/assets/entry-client-ded10d36.js(64f90b4f1dbfa8000894079d--XXX.netlify.app)        | 109.1 KiB | 67.2 KiB

3. Route Config vs. Functions

I honestly like the readability of using a more Remix-like approach via functions for routeData vs. a Next approach of Objects like meta but that's just a PO.

Can't wait for 2! 👏

8 replies

caseybaggz Oct 6, 2023

@ryansolid ah, thanks for that feedback. I'm not sure it's the router that's the issue but maybe what SS is doing to render the routes if that make sense? Like the more "complex" routes I create, the weirder stuff happens and it's only breaking around the routeData fetchers (like mentioned above).

So the routing and route creation absolutely works, but the page rendering and delivery of the server data to the routes is what breaks - and this routes that are nested 2 layers deep and using Outlet. So for example, page refresh - breaks and doesn't deliver the data on the nested routes but if you navigate out and back in using the SR A - totally fine. 🤷‍♀️

caseybaggz Oct 6, 2023

The only thing I haven't tried yet using the @solid/router components and manually bring in the routes and routeData via Route lists. It is on my TODO list though just to figure a little more out on what is happening and why.

Just a follow up - went back through the Solid Router docs just in case new stuff was pushed since I've started my project and I do think it might be both some changes I can make in my project to see if I can enhance the router experience a little more with the Outlet being used before I go all in on just ditching FileRoutes.

Keep ya posted.

caseybaggz Oct 15, 2023

OK, @ryansolid just a follow up - I went ahead and migrated all the Outlet, Routes, and A components to use @solidjs/router and I'm still getting weird page/data issues with double nested routes via Outlet. I'm almost certain this is a FileRouter issue from the Solid Start Side.

caseybaggz Oct 16, 2023

@ryansolid found some very interesting information out just now regarding this FileRouter issue that maybe we focus on a little more in the Beta 2 docs. So, I noticed that I've seemed to be overlooking the @solidjs/router data param for all the child routes being presented via Outlet and have started working on taking advantage of that for performance.

To my surprise, by adopting using the data function from routeData has fixed this issue and also allowed me to not really need to deeply reference route params since they are being referenced and collected in the parent routeData function. This is a game changer for my app and will definitely make sure this isn't overlooked in the docs when SS Beta 2 releases. 💪

ryansolid Dec 8, 2023
Maintainer Author

Unfortunately this whole pattern is changing with the latest for the router. I do recognize it was under documented which is unfortunate.

katywings · 2023-09-08T11:54:25Z

katywings
Sep 8, 2023

That's some great news to hear <3! @ryansolid thank you for the hard work you and the team are putting into this, finally making the web a solid place 😁! And a special thanks for not only the fun, enjoyable, explorative hours you are investing, but also the boring, unrewarding, yet still important ones!

Now that Astro seems to be ultimately out of the table for SolidStart, I am wondering if you have plans to implement sitemap.xml / RSS-feed generation Astro features directly into Start/vinxi, or if you want to keep Start on the more lightweight side?

As you might know, I am implementing a CMS on top of start and waited with my own implementation of sitemap/RSS, because I wasn't sure what to expect from the previously announced start->Astro transition 😅.

0 replies

jcalfee · 2023-09-30T13:30:17Z

jcalfee
Sep 30, 2023

Thanks for the update!! Not sure what this means. Is there an example of this somewhere?

If you wish to use a server function just use a server function.

2 replies

appurist Dec 14, 2023

I may be wrong here, but I believe this means simplify the API to just use server$ everywhere rather than sometimes using createServerRouteData and createServerRouteAction.

ryansolid Dec 18, 2023
Maintainer Author

I meant that instead of having 2 versions createServerData$ and createRouteData we just have one version and you use server$ where you want it. That being said. "use server" is where things have landed. But same idea applies.

christhornham · 2023-12-21T15:41:11Z

christhornham
Dec 21, 2023

@ryansolid I just created a new solidstart project and root.tsx is gone. Above, you mentioned the removal of capital letter Components that belong only in the root. However, it appears the docs aren't up to date on this change. The docs still reference root.tsx and use capital letter Components everywhere. Do you have any references for converting Beta 1 projects to Beta 2 projects?

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SolidStart Beta 2 #1052

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 6 comments 15 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

SolidStart Beta 2 #1052

ryansolid Sep 6, 2023 Maintainer

Summary of Changes

1. Rebase to Nitro's adapters and Vinxi

2. Merge the Start CLI with the Solid CLI community project

3. Update the entry point

4. Stop aliasing other libraries through Start

5. Update the router

6. Better Middleware setup

7. Revisit server$ vs use server and island$ vs use client

Moving Forward

Replies: 6 comments · 15 replies

ryansolid Sep 7, 2023 Maintainer Author

1. Nested routing with multiple Outlet don't work

2. client-entry ships unused JS

3. Route Config vs. Functions

ryansolid Dec 8, 2023 Maintainer Author

ryansolid Dec 18, 2023 Maintainer Author

ryansolid
Sep 6, 2023
Maintainer

7. Revisit `server$` vs `use server` and `island$` vs `use client`

Replies: 6 comments 15 replies

ryansolid Sep 7, 2023
Maintainer Author

1. Nested routing with multiple `Outlet` don't work

2. `client-entry` ships unused JS

ryansolid Dec 8, 2023
Maintainer Author

ryansolid Dec 18, 2023
Maintainer Author