support SPA mode

[dishuostec]

#383
Add --spa --ssr, --hashbang to dev, build and export command.

Without --spa --ssr=false, --hashbang, nothing changed.

With --spa --ssr=false:

• Raise 404 when no route match.
• Auto create index.html from template.html.
• Skip create server middleware (no SSR).
• Skip craw pages when export.

With --hashbang:

• Hash-based routing (auto created from sapper client route and support jump to anchor on current page).

Example spa-template.

[saabi]

Hey, very cool PR here! I've been looking for something like this.

I have a couple of questions:

• I want to run it with a SPA server that serves static files and then a single index.html for all other routes, so hashes wouldn't be needed. Would it be possible to generate the site without hash-based routing?
• What's the behavior with respect to accessing an API server in preload and elsewhere?

[alexdilley]

@saabi my guess is the static site host would be responsible for supplying the client with index.html for unknown routes, typically via redirect/rewrite rules (e.g. Netlify docs).

[saabi]

@alexdilley Yes, that's the way it works.

My questions are concerning the output generated by the PR. Regarding the first question, I want it to generate non-hashed routes.

[dishuostec]

Hey, very cool PR here! I've been looking for something like this.

I have a couple of questions:

• I want to run it with a SPA server that serves static files and then a single index.html for all other routes, so hashes wouldn't be needed. Would it be possible to generate the site without hash-based routing?
• What's the behavior with respect to accessing an API server in preload and elsewhere?

@alexdilley

1. Currently this PR only generate bash-based routing, I think may be we need another option to control router mechanism.
2. I just disabed sapper middleware (ssr, sapper server side api) and changed to hash-based routing, so preload is only run at client side.

[saabi]

1. Currently this PR only generate bash-based routing, I think may be we need another option to control router mechanism.

I haven't dug into the code, but reading around it seems there wouldn't be much more to do to Sapper itself and probabl to this PR to handle non-hash based routing because it's basically what it does already, am I right? Just asking because you're surely in a better position to judge than me at this point.

[dishuostec]

I haven't dug into the code, but reading around it seems there wouldn't be much more to do to Sapper itself and probabl to this PR to handle non-hash based routing because it's basically what it does already, am I right? Just asking because you're surely in a better position to judge than me at this point.

Yes, Sapper use pathname routing. Sapper can handle any valid route with build-in server.

I choose hash-based routing because when creating SPA I want use dependency as less as possible. Use hash-based routing I just need a place only support serve http request for static file, no more complex config for server rewrite.

[dishuostec]

I think We need two switch to control 6 scenarios:

scenario	purpose	built-in server	ssr	bash route
1	origin develop, build	1	1	0
2	origin export (static pages)	0	1	0
3	develop without ssr, to reduce compile time	1	0	0
4	develop and build pwa, serve via built-in server	1	0	1
5	export PWA use pathname routing (single index.html, need external server config)	0	0	0
6	export PWA use hash routing (single index.html)	0	0	1

My project is working in cordova, so 4 and 6 are what I need. And I can just change some switch to turn the project to working on modern browser in the future.

@saabi Is 5 that what you expect?

[saabi]

@dishuostec Nice work! Yes, 5 is what I need.

I haven't tested it yet, but splitting --ssr from --hashbang does it?

[dishuostec]

I haven't tested it yet, but splitting --ssr from --hashbang does it?

use

{
  "scripts": {
    "dev": "sapper dev --ssr=false",
    "build": "sapper build --legacy --ssr=false",
    "export": "sapper export --legacy --ssr=false"
  }
}

[benmccann]

Thanks for putting together this PR! Sapper never had a good method of handling configuration, which made it difficult to know how to integrate this feature. However, that's been addressed in SvelteKit and we'd like to add the feature there (sveltejs/kit#231). I'm going to go ahead and close this PR since we won't be adding the feature to Sapper, but if you'd like to try taking a stab at adding it to SvelteKit we will review PRs for this feature there

[frederikhors]

@benmccann are you saying SPA mode is still NOT possible in svelte-kit?

[benmccann]

It's not yet, but we'd like to add it. It should be a pretty easy feature to add

[frederikhors]

It should be a pretty easy feature to add

Rich wrote these exact words years ago for Sapper! LOL! 😄

[tommywalkie]

Jokes aside, in their defense, during this year they had to rethink the whole Sapper architecture from a self-made one to using Snowpack, and then recently going for Vite for SvelteKit.

[frederikhors]

I love Rich, Svelte and all of you guys.

No problem. We will wait. The work you are doing is crazy! ❤️