Shall V1 support Filesystem Routing?

[brillout]

See #578 (comment).

Edit: example of what the propsed FS-less design looks like is on the way. (You may be surprised how much easier it is than you think.)

Edit2: I've an idea how to make FS routing work very well with the V1 design. I'll show an example. We can consider this dicussion as "closed" in the meantime.

[samuelstroschein]

The comment states

I'm actually increasingly thinking of completely removing Filesystem Routing, including the aforementioned glob proposal. Single Route Files really are superior for anything non-trivial.

Can you elaborate why?

[samuelstroschein]

The example contains a whopping 4 config files and 1 config directory for 2 pages though :/

[brillout]

Precisely, that's something I want to avoid. With singleConfigFile: true you only have one +config.js (the "root" one: pages/+config.js). I.e. the proposal is to remove/make the option singleConfigFile always true.

[samuelstroschein]

It would help if you can provide an example of a single file config code base

[brillout]

👍 I will.

[AaronBeaudoin]

I think part of the problem here is that even if you make an example project with a single config file, the number of pages doesn't showcase what happens to the config in real-world app. Once I've got 100, 50, or even 10+ pages, I'd imagine a single config file would start getting pretty inconvenient to navigate and maintain when compared to filesystem based routing.

[lutzissler]

I definitely don’t need FS routing.

[iMrDJAi]

I'm against removing filesystem routing, it's actually a neat feature and straightforward to implement, I usally just copy/paste an existing directory, then renaming it, start working on it, then ta-da! a new route has been created! No extra configuration required as VPS promoted from the beginning.

Also, from vite-plugin-ssr.com:

Stable foundation
Frameworks need to constantly keep up with the ecosystem, whereas do-one-thing-do-it-well tools can quickly stabilize.

Actually, vite-plugin-ssr is already stable: breaking changes are only about improving the design of vite-plugin-ssr which means that you can expect your integrations to keep working in the future.

This change would be against this statement, which would break our integration.

[brillout]

Creating new pages is actually easier with the proposed FS-less design and, to be clear, it has a single pages/+config.js file, see #630 (reply in thread).

[iMrDJAi]

@brillout After taking a look at the example you have provided, I see that it's not that complicated TBH. However, I'll still have to modify +config.ts every time I create a new route, which is kind of annoying.

[brillout]

I think, all-in-all, it will be better. We'll have plenty of time to experiment with the V1 design beta on the v0.4 branch before we set it in stones in the v1 release. You'll / we'll see.

[AaronBeaudoin]

Filesystem based routing in my opinion provides the smoothest DX of any routing approach. Having to edit routes in a config file somewhere every time I create a new page is a poor experience, because:

1. It's just inconvenient. I want to just create a new page component file and start working in it right away without having to make additional changes elsewhere. Managing routes as paths in a filesystem is a more natural way of thinking and working.
2. I can no longer immediately reason about the structure of my site just by looking at the project structure in the filesystem. To get a clear picture, I need to look inside the config, since my page files might not necessarily correspond with my actual routing structure. (Sometimes this is desired, but I would consider it something that should be avoided whenever possible.)
3. As my site grows, so does my config file. Therefore, the idea of it being a "neat summary" of my app is only true to the extent that my app has a concise routing structure to begin with. For a large app, I'll end up with a long, bloated config file.
4. Routing is not really a project config concern but a regular development workflow concern for managing pages. Moving it into a project config file means I now have to revisit that file frequently, when I'd rather just set it once and forget it.

Just being honest here: If VPS dropped filesystem based routing, the first thing I'd need to do for my workflow is start investigating how to implement the same functionality myself. Doing that would really makes me wonder whether I shouldn't just create my own custom SSR implementation myself on top of Vite's low-level APIs.

I've actually built on top of VPS's current filesystem based routing in my own project, adding the ability to create server-side functions in my site's routing structure by adding whatever.func.ts files anywhere I want in the filesystem right along with my pages. It's basically my own custom version of SvelteKit's +server "API routes". In my opinion it is super elegant.

I'm currently "all-in" on filesystem based routing, and I'm having a hard time seeing how switching to managing my routes in a config file would make my workflow better. I'm not meaning to roast all the careful thought I'm sure you've put into this. I'm open to hearing more of the philosophy behind routing inside a config file. This is just my take, based on how I work.

[lutzissler]

I – having said I don’t need FS routing above – can see your use case. Our typical projects, in contrast, require (sometimes deeply) nested views which just can’t be represented well in FS routing. For an example, look at this:

From this file structure, you can’t tell how many routes there really are because nested routing functionality is hidden in the SFCs.

(Plus, and this is especially bothering me with FS routing: Having several files called ‘index.page.vue’ open at the same time just isn’t great DX in my opinion.)

[AaronBeaudoin]

I can see your point. Filesystem based routing certainly isn't a silver bullet for all use cases. But I'm actually curious about what kind of routing setup you have that doesn't work with the filesystem approach.

Filesystem based routing also doesn't necessarily mean all your page files need to be called index.page.vue either. If the pattern of the filename was customizable, you could avoid that issue by adding an extra "name" component into the filename like Home.index.page.vue or Projects.index.page.vue where that first part is only for visually distinguishing the files. Or you could have some .page.index.vue suffix pattern (imitating .page.server.vue or .page.client.vue) which means that the preceding text will be ignored, so it exists merely as a label, and the purpose of the file will always be functionally equal to index.page.vue. That hinges on the existence of configuration options allowing you to set something like that up, however.

So I think that there are definitely solutions to your concern. But again, they hinge on giving the user the configuration options to customize how filesystem based routing is matched in their particular project. In my opinion, we could have filesystem based routing off by default, opt into it with a sensible defaults via a fsRouting: true sort of option, and further customize how it works with a fsRouting: { ... } optional advanced config. I really just think that optional advanced config is really important.

[brillout]

Having several files called ‘index.page.vue’ open at the same time

Can't VS code be configured to show the full path instead of merely the filename?

bloated

I'm playing around with a single config file without FS routing. And, yes, it does feel a bit bloated and repetitive.

I've an idea for supporting FS routing in a way that works with V1. I'll show you an example. I think we can close this discussion in the meantime.

"API routes". In my opinion it is super elegant.

FYI https://telefunc.com/event-based#naming-convention. In general, Telefunc is far superior than API routes. That's why VPS doesn't implement any: the recommendation is to use a properly dedicated tool instead of half-backed API routes.

[hemengke1997]

For simple usecase, filesystem routing is essential. E.g. Each page is unrelated to each other.