One Month of SolidStart Beta

[ryansolid]

I wanted to write something up since we've been in beta for over a month now. It's been a busy month for me, I've travelled to 6 different cities and spoken in twice as many events. All important tasks but haven't lent to me being as involved in the project as late as I'd like. And similarly, Nikhil has been gearing up for an international move and hasn't been around recently as well.

I'd like to say I've been super impressed by people stepping up to contribute PRs. Especially to help with docs (yes I know they are out of date at the moment, CI broke, another thing to get done). But at this point we have 91 contributors and 2700 stars on github. I've even been talking to several companies betting on SolidStart for their projects. It took Solid's core repo years to get to this point.

Still in even a short time and thanks to the hundreds of reported issues, I want to talk about some major topics as it's clear we have some work to do. As always we need help and the best way to do that is to communicate and categorize so we can break this down to more workable pieces. This won't cover everything that is open but I've noticed a few places where we can make big wins and deserve our focus.

As always I want to put ideas out there early rather than suggest I have the solution. So if you have thoughts on these topics please join the discussion.

Features

1. Client Render Mode

It works by rendering the root component down to the body at build time instead of request time but there have been many specific errors since it does render it on the server. Some deployment build processes have seemed to choke on this for some reason. We also aren't handling global redirects properly in this case yet. There are several open issues in this area that are worth addressing.

#303
#383
#406

2. Static Site Pre-Rendering

The current adapter is too simple. It auto looks for static routes with the ability in the config to specify some routes. There is a lot more that can be done here and these issues really highlight some of the shortcomings.

#156
#285
#325
#381

3. Environment Variables

This is just missing and me misunderstanding what VIte actually does for us here. More than happy to see someone PR something similar to what you find in other projects.

#480
#556

4. TypeScript Improvements

I'm going to bucket them because there are many. But most of this comes down to the repo originally being written in a way that didn't have a build process that kept things really fast as we iterated. Now we need to do better here. There are other gaps here too.

#140
#255
#393
#421

5. Only processing .jsx/.tsx files

I think this causes more issues than we realize, but currently server$ only work there and if people have external libraries trying to do this and it compiles down to .js/.ts we aren't picking them up. There is a direct issue but I wonder how many hiccups are actually related to this.

#408

6. Path/Module Resolution & Code Splitting Issues

We've had a lot of these historically and have worked them down a bit but there are still issues around this, especially for SSR.

#127
#322
#401
#402
#403
#407
#489
#522
#558

7. Automatic Adapter Detection is a Mess

We probably should just get rid of it. We had this hope to help with automatic deployment pipelines but this isn't really working well at all.

#286

API Reflections

1. createServerData$ Keys

Something that has become clear is that the API for key being reactive is not obvious. It's also a bit awkward if it is the only way to pass data to the server function. Being double purpose makes a lot of sense for a lot of things and the fact that it does push people to encode this data means caches will work better but the API is very non-obvious hidden on the object. In createResource it is much more obvious that this is for that. While other than renaming the property here I have no direct resolution I think we should consider this in relation to other observations. For the $ to make sense we need to follow a convention like first argument is hoisted.

2. Confusion between createServer__$ and createRoute__

This could come down to teaching/docs but the reason I wanted to introduce createServerData$ when it was completely unnecessary to do so was to streamline it. We could have just not and said use a server$ when you want to. We were thinking about extensibility. Writing other $ functions.

So far this attempt at reducing complexity feels like it has backfired. It doesn't give us savings in concept only in typing. People still learn server$ first. Sure we can say $ always refers to the first argument but it doesn't feel good. I think its more than just a gut initial reaction. I may have been wrong about this and should have only introduced createRouteData and made people consciously wrap with server$. I don't like that per se, but I hate having confusion there.

One option suggested was to make them both createRouteData and just append the $ to make it server. This feels better but I don't know how much it alleviates things. It means that $ isn't just for hoisting but it means server.

Another consideration I didn't have at the time is we didn't have experimental Islands back then. And with experimental Islands you are going to be using createRouteData or even createResource and the server versions while they work don't add anything here since they are always on the server.

3. Progressive Enhancement/RPC bridge

I'm pretty happy with how clever we've been here, but there are gaps. The most prevalent one to me is that under certain situations these functions are just functions that load data that aid in server rendering. In others, they are their own API response. This is an awkward tension. Thankfully it applies more to Actions than Data but it is still there nonetheless. Like recent questions of route data functions setting headers. Our rendering does that via JSX elements. In so the render flow decides how things work out. redirect vs using the router JSX to redirect is a similar consideration. In view is generally better for error handling generally but here we are. We definitely need a way to address this but it's part of that.

Similarly with actions and redirect handling etc.. Having to work with no JS means straddling this line with base HTTP responses and just JSON APIs. It's all within the wheelhouse but being general here with the primitives gives more room for confusion. Like right now you don't need to use Forms for this pattern. I think that is great but it means that you author stuff slightly differently. It makes sense because without Forms there is no progressive enhancement. The abstraction works well in both places but it is a bit of a different experience for authoring the action code itself. Again I can point at the documentation but that's the last line. We should be looking and reflecting on the APIs.

Conclusion

Ok there is a lot of stuff here. A lot of learning. Which is a large part of working through a beta project. I think a lot of the decisions here are incredibly nuanced especially around the API. I don't think we've done poorly just weighing impressions and feedback. Part of this is filtered obviously by the number of bugs, but I feel like if we can focus in those key areas a lot of main pain points diminished.

Well, enough writing ... back to work.