if we don't pre-render all pages, then we need a production server

[nitedani]

I tried creating this folder structure:

pages
	index
		+Page.jsx
	posts
		@id
			+Page.jsx

prerender: { partial: true }
pnpm build
cd dist/client
pnpx sirv-cli --single

If I open /, it loads the index page.
If I open /posts/1, it still loads the index page(unexpected).
If I open / then call navigate('/posts/1'), it navigates just fine.

if we don't pre-render all pages, then we need a production server

Why is there such a limitation?
Couldn't the client-side router handle the initial navigation?
Can we support a static dist/client output even without any pre-rendering?

[brillout]

Each URL needs to be pre-rendered so that an HTML file is generated. That's why partial: true requires an SSR server.

That said, SSR can be disabled for some pages: pre-rendering will then render an empty shell for these pages. That achieves what you want.

[nitedani]

When the dist/client folder is served, initial navigation to pages which don't have a html file falls back to serving the index page html, if the static host is configured to do so.
My idea is, that the client-routing runtime could render the correct page based on the url, even if there is no html file generated for that page.
Taking it even further, an index.html file could be generated even when prerendering is completely turned off, and the dist/client folder could be served as-is.

Do you think this is worth it to implement in Vike? I don't need this, I just had this idea. (someone asked about this on discord)

Quoting:

japfohl — Yesterday at 2:40 PM
I’ve done that much so far. But it seems that there still needs yo be a server if I want to handle routes like /todos/@todoId. I’m looking to keep absolutely everything client side but still have the dynamic routes.

[brillout]

I want to handle routes like /todos/@todoId. I’m looking to keep absolutely everything client side but still have the dynamic routes.

I see. That makes sense and, yes, unfortunately there currently isn't a way to achieve that.

falls back to serving the index page html, if the static host is configured to do so.

Indeed, if some static host supports that then I also think that generating a fallback HTML could work.

It would be nice to support that use case. (Although it isn't the highest priority.)

[brillout]

Created a feature request for it: #1476. It's quite a nice use case.