Single File Page. (Being able to define everything in a single file `.page.js`.)

[brillout]

Instead of having several page files (.page.js, .page.route.js, .page.server.js, .page.client.js), we would define everything in .page.js (while vite-plugin-ssr automatically statically extracts the relevant parts like in https://next-code-elimination.vercel.app.)

Many people have expressed a longing for this, but I'm on the fence. Simply because I highly value clarity and simplicity: it's obvious and simple what the .page.js, .page.route.js, .page.server.js, and .page.client.js files are about, whereas if we merge everything in .page.js it becomes less clear what is run in what environment.

[brillout]

When I stumbled across this project my immediate thought was "I could make a clone of Remix with this" https://remix.run/
I really like the clean API they have https://www.youtube.com/watch?v=4dOAFJUOi-s&t=1281s

@deckchairlabs what is it you like abour their API? Glazed over the first minutes of the video; didn't see anything special.

Yeah, being able to define everything in *.page.ts files would be so great.

I'm on the fence. Simply because I highly value clarity and simplicity: it's obvious and simple what the .page.js, .page.route.js, .page.server.js, and .page.client.js files are about, whereas if we merge everything in .page.js it becomes less clear what is run in what environment.

[brillout]

@chrisvariety

having it all in one file and shaking out the server-side dependencies (see https://next-code-elimination.vercel.app ) could be a nice enhancement.

I'm on the fence. Simply because I highly value clarity and simplicity: it's obvious and simple what the .page.js, .page.route.js, .page.server.js, and .page.client.js files are about, whereas if we merge everything in .page.js it becomes less clear what is run in what environment.

[brillout]

One thing we could do is to remove the .page.route.js file (instead, the user export { route } in .page.js). We then have:

• .page.js => Node.js & Browser
• .page.server.js => Node.js
• .page.client.js => Browser

The user quickly and naturally understands that the page types .page.js VS .page.server.js VS .page.client.js are only about where code runs. (As things currently are, the .page.route.js adds semantics to what .page.* types are about and can lead to confusion.)

Isn't it annoying to have to create all these files?

Almost always the .page.client.js is written only once as _default.page.client.js. So the user ends up having to write a max of 2 files (.page.js and .page.server.js) per page, instead of only one file per page. Yes, it's slightly annoying to have to create 2 files instead of one, but it would, IMO, be worth it in terms of clarity.

[deckchairlabs]

@brillout

@deckchairlabs what is it you like abour their API? Glazed over the first minutes of the video; didn't see anything special.

I suppose what I like is the fact they separate the "Loading" of data (addContextProps) and handling of an incoming "Action" (form POST for instance). Although in saying that, I do like that with this plugin, there isn't as much "magic" as appears to be happening with Remix.

In my little playground I'm handling POST requests within a *.page.server.ts within addContextProps.

https://github.com/deckchairlabs/vite-remix-clone/blob/main/pages/posts.page.server.ts#L11

[brillout]

I do like that with this plugin, there isn't as much "magic" as appears to be happening with Remix.

Exactly: vite-plugin-ssr aims to be non-invasive and to let you having control over your stack architecture.

https://github.com/deckchairlabs/vite-remix-clone 😍 Are you doing it for yourself or do you want to make it an open source proejct?

In my little playground I'm handling POST requests within a *.page.server.ts within addContextProps.

It's actually a common practice to do all kinds of things in addContextProps(). An alternative is to do it before renderPage() is called.

[deckchairlabs]

https://github.com/deckchairlabs/vite-remix-clone 😍 Are you doing it for yourself or do you want to make it an open source proejct?

At the moment just playing around, but eventually!

[doeixd]

Exactly: vite-plugin-ssr aims to be non-invasive and to let you having control over your stack architecture.

This plugin is great! And I think the default behavior is very clear and easy to reason about, especially with the well written docs.

However, I would love the ability to hook into the plugin's get page functionality, so that if someone wanted to have more control (and maybe implement a single file page, or their own framework with out this plugin's defaults), then they have the possibility of doing so at their own risk.

This could be a dumb idea, but I would love to know what you think?

[brillout]

@doeixd We can start by removing the .page.route.js file and see how it goes. I'm not sure that we'll achieve to remove .page.server.js and .page.client.js in a 1. DX friendly way, and 2. without too much burden on the vite-plugin-ssr source code; things should stay simple. But I'm happy to explore this area. To get started you can make yourself familiar with Vite/rollup's architecture, e.g. https://vitejs.dev/guide/api-plugin.html#transforming-custom-file-types.

[gryphonmyers]

I think it's actually clearer having the route in a separate file. There's no confusion as to whether it's isomorphic avoiding questions like "does the route information go in .server or .client?", "can it go in both?"

I also definitely prefer the clarity of having separate server and client files. This has been so much nicer to work with than other frameworks that blur the line between server and client.

[brillout]

I also definitely prefer the clarity of having separate server and client files. This has been so much nicer to work with than other frameworks that blur the line between server and client.

Yes, that's something I highly value. This actually has been my main reason for pushing back against the many people who expressed a longing for having everything defined in a single file. But I can see that there is a solution here. For example, if the default is to have separate files, the docs always use sperate files, and having everything defined in a single file would merely be a convenience for "pro" users that know what they are doing.

I think it's actually clearer having the route in a separate file. There's no confusion as to whether it's isomorphic avoiding questions like "does the route information go in .server or .client?", "can it go in both?"

That's a good point. Although strong docs can go a long way in clearing this kind of confusion out: simple and strong contracts between user and vite-plugin-ssr, API docs that are clear and complete, and guides that reflect the path of least resistance for 90% of use cases, while those 10% complex use cases are expected to (and usually inherently) require brain power from the user.

[gryphonmyers]

But I can see that there is a solution here. For example, if the default is to have separate files, the docs always use sperate files, and having everything defined in a single file would merely be a convenience for "pro" users that know what they are doing.

Supporting both sounds like a good call. It of course increases the complexity of the codebase a bit, but if it's serving the preferences of a significant body of users, I suppose it is a relatively harmless addition.

That's a good point. Although strong docs can go a long way in clearing this kind of confusion out: simple and strong contracts between user and vite-plugin-ssr, API docs that are clear and complete, and guides that reflect the path of least resistance for 90% of use cases, while those 10% complex use cases are expected to (and usually inherently) require brain power from the user.

Yeah I suppose if we make it super clear that routing information MUST go into the isomorphic page file and will simply be ignored in the other files, then maybe there's not that much room for error.

[doeixd]

I also definitely prefer the clarity of having separate server and client files. This has been so much nicer to work with than other frameworks that blur the line between server and client.

This is a good point! Although I think it is possible to make a single file page, where it is clear where client/server functionality takes place. Just look at the success of projects like Next.js, Remix.js, and SvelteKit. They all handle this by exporting functions that clearly describe where the functionality takes place. Personally, I think something like this is just as clear as having separate files. All the functionality of the page is easily accessible and doesn't require 4 separate files for a simple page.

Supporting both sounds like a good call. It of course increases the complexity of the codebase a bit, but if it's serving the preferences of a significant body of users, I suppose it is a relatively harmless addition.

This is a great point! This functionality would require significant additional effort which may be out of scope for this project. And not adding it makes a lot of sense.

[brillout]

Agreed.

Personally, I think something like this is just as clear

I agree.

increases the complexity of the codebase a bit

It may not increase the complexity much if it ends up only being a preprocessing step that is independent of the rest of the code.

[gryphonmyers]

I also definitely prefer the clarity of having separate server and client files. This has been so much nicer to work with than other frameworks that blur the line between server and client.

This is a good point! Although I think it is possible to make a single file page, where it is clear where client/server functionality takes place. Just look at the success of projects like Next.js, Remix.js, and SvelteKit. They all handle this by exporting functions that clearly describe where the functionality takes place. Personally, I think something like this is just as clear as having separate files. All the functionality of the page is easily accessible and doesn't require 4 separate files for a simple page.

Supporting both sounds like a good call. It of course increases the complexity of the codebase a bit, but if it's serving the preferences of a significant body of users, I suppose it is a relatively harmless addition.

This is a great point! This functionality would require significant additional effort which may be out of scope for this project. And not adding it makes a lot of sense.

It gets less clear when you have dependencies. How can I be guaranteed that node-fetch isn't making it into my client bundle? Magic?