SolidStart Beta 2: Month 3

[ryansolid]

Another update for SolidStart. I'm very happy how this feedback loop has been working and we are getting much closer to 1.0 now. I've been building and deploying projects on all the major providers and getting bugs fixed in Vinxi and Nitro along the way the past couple weeks so things are coming along quite nicely.

Really just down to consolidating on some naming details. So just want to put stuff out there and get some opinions. And to ask if there is anything else people want to see for 1.0.

Environment Variables

I feel like this topic probably need to talk about to see if there is some base conventions we should be setting differently. Currently we compile in VITE_ prefixed ones at build time the way Vite recommends. Should we stay with this or use a different convention. I don't particularly care that it is Vite since we are on Vite and this could make migrating Vite projects easier, but there is an argument that something like Astro's PUBLIC_ convention could be better.

Definitely interested in people experience with environment variables so far and if we can do something better to handle them.

Router Conventions

Honestly, I'm not too interested in picking these apart but adding the . to do unnested paths does ask if we need an escape character so you can put . in your URLs. Or maybe use a different delimiter. To be fair this only applies to pages. API routes don't have nested routing and don't support the syntax, which means that you can still have like api.json.ts and have it work. But even this I suppose is a question since maybe we should at least support the . syntax there even if nesting has no meaning.

---

That's really all I got. I'm pretty happy getting docs rolling and getting us to our goals. Please comment with any feedback or other things you'd like to see. It's getting pretty real about now. Thank you all for your participation.

[birkskyum]

I think PUBLIC_ is a lot more intuitive than VITE_, so it's probably clever of Astro to a stance here. There are examples like this where people feel the need to add an extra PUBLIC anyway (import.meta.env.VITE_PUBLIC_BASE_PATH), to clarify that the VITE key is a PUBLIC key.

[atilafassina]

My issue with VITE_ vs PUBLIC_ is that right now we need to use VITE_ to server-only variables, even if we don't intend them to reach the client-side bundle. We trust Vinxi to split "use server". In this case, PUBLIC_ isn't a good name.

• PUBLIC_ for env variables that are ok to end up in the client-bundle
  or
• SECRET_ for env variables that will always be striped from client-bundle

[birkskyum]

Or CLIENT_ (client-only), SERVER_ (server-only) and PUBLIC_ (both)

[timothyallan]

I'm all for CLIENT_ and SERVER_ if it's possible as It's crystal clear what each is going to do. PUBLIC I'm iffy on. If someone wants to expose a variable to both, they can just duplicate the variable in the specific .env file.

[mtt-artis]

I'm struggling to see a use case for CLIENT_ as client only. Is it for tree shaking ? What's the problem if the back can access a client env ?

[ryansolid]

Given how opened ended this is I'm tempted to keep things as VITE_. VITE_ just means build time versus runtime so given that split yeah I think we stay the course at least until Vite does something different. Thanks for the discussion.

[timothyallan]

+1 on not having a library specific prefix for public vars. Also future proofs for less confusion down the road if there's a split from Vite as well.

[gabrielmfern]

That's really all I got. I'm pretty happy getting docs rolling and getting us to our goals. Please comment with any feedback or other things you'd like to see. It's getting pretty real about now. Thank you all for your participation.

Talking about docs, would love to see something on opting out of file-based routes. I know that we can just use plain Route, but what I wanted to really have is a way to know what FileRoutes does without having to read through its code.
Wanted to implement it with the plain Route and have the same functionality without having to use the same routing mechanism.

[sh1man999]

+1 I am for
PUBLIC_

Why they want to abandon FileRoutes ?

[lxsmnsyc]

@sh1man999 what he meant is that since FileRoutes are optional part of SolidStart, there's is no specific guide on how to handle it assuming you want to implement your own router preference.

[ryansolid]

It probably will be interesting to see what we can do here. It probably starts with the first other router integration. Using other routers is completely doable with this setup but requires a few things not documented. Bypassing the FS routing altogether is trickier because there are things that are very difficult without FS routing, or some sort of static analysis. The biggest being mapping route paths back to their code entries. It doesn't matter for CSR mind you, but for SSR it is definitely a hit.

[ryansolid]

No one commented on the File Routing dilemma.. It occurs to me maybe the "." syntax isn't even needed since we have () you can always make a different path by adding a () to it. Not suggesting group layout.. simply adding it as a descriptor.

Using the example from the docs:

|-- routes/
    |-- users(list).tsx
    |-- users(list)/
        |-- index.tsx
        |-- projects.tsx
    |-- users
        |--[id].tsx
        |--[id]/
            |-- index.tsx
            |-- settings.tsx

As you can see the listing page no longer matches with the details section. Alternatively it could be:

|-- routes/
    |-- users.tsx
    |-- users/
        |-- index.tsx
        |-- projects.tsx
    |-- users(details)
        |--[id].tsx
        |--[id]/
            |-- index.tsx
            |-- settings.tsx

In some ways this isn't as clear as . but it doesn't add any new syntax and is consistent. No worrying about escaping or delimiters. It doesn't add any additional files but I suppose it adds an additional folder compared to using ..

[LexSwed]

Is tsx in the folder name a mistake?

|-- users.tsx
|-- users.tsx/
    |-- index.tsx

I think users(details) is definitely better than users.[id] because to me . is easier understood as nesting, like unix path, ./users/./id. Plus, it is also already used for nesting in Remix. Not to say it's best, but it is designed in a way that would correctly represent routes structure in tree view of any editor. E.g. index route always comes first with leading _: users._index.tsx, and layout last concerts.tsx, unless layout needs to be avoided, with trailing _: concerts_.mine.tsx.

Copied from the docs:

app/
├── routes/
│   ├── _index.tsx
│   ├── about.tsx
│   ├── concerts.$city.tsx
│   ├── concerts.trending.tsx
│   ├── concerts.tsx
│   └── concerts_.mine.tsx

Ideally, Solid aims for the same clarity, when just by looking at the file tree, it's clear what's nested, what's layout etc.
F.e. I like renaming convention, but it puts layouts far apart from the routes they wrap:

app/
├── routes/
│   ├── (www)
|   │  ├── index.tsx
|   │  └── about.tsx
│   ├── app
│   │  └── index.tsx
│   ├── privacy
│   │  └── index.tsx
│   ├── (www).tsx // all the way here, any route is above
│   └── 404.tsx

[ryansolid]

Yes let me fix that.

I think Remix probably did this full reversal for that reason. V1 Remix uses the . like I did in the last release, but yeah it feels opposite. I will say the () leading have a similar impact as _ so your index files generally are first in our setup.. but mixing files and folders always has an ordering issue which is why Remix went flat I imagine. In any case using the ability to differentiate by description that is removed between () feels more consistent with what we are doing I think.