Abstract prerendering

[johnnysprinkles]

Rendered

[benmccann]

This line is a bit outdated - the PR was closed

[johnnysprinkles]

Here's how this would look, not submitting for PR or anything but just wanted to demonstrate the changes we'd need to make. Not very deep changes:

https://github.com/johnnysprinkles/kit/commit/963f0471184c245799744de7befa4ac85e82c56d

I think something like this would ultimately be a prerequisite for doing i18n as well. We'd ultimately need a prerenderer that can render each route multiple times based on an arbitrary number of dimensions, and presumably we'd pass information about which value for each dimension via query string. That communication is going to be different at runtime and at build time, for example the current location at runtime might just be geolocated and not use the query string at all. I'll post more thoughts in the i18n mega thread.

[johnnysprinkles]

I really think we should reconsider the discussion in sveltejs/kit#1511 that got shut down abruptly by a @Rich-Harris comment (sveltejs/kit#1511 (comment)). cc @pz-mxu

It's quite useful to be able to pre-render pages for which params aren't known at build time, and I certainly plan on doing just that.

[johnnysprinkles]

Another possible approach would be do not do any of this, and let client-only code that needs to know query or route params simply not use the page store and get it directly from location. The only issue there is the client doesn't know the regex pattern or positional list of param names. We could just put that somewhere where the client code could get it.

[johnnysprinkles]

Oh what am I thinking? runtime/client/renderer.js already knows how to parse the URL according to the current route. All I'd need to do is make it re-run its page store generation logic at the appropriate time, to overwrite the wildcard one that was captured in the page store from build time. Let me investigate this path.

[johnnysprinkles]

So just to summarize, I have two approaches to demonstrate and a couple others to consider:

1. Redefine what the page store means, when pre-rendering is involved. Currently it means "the values as they were at pre-render time." This proposes that they become "the values as they currently are for the current request at runtime." Might be rather invasive to redefine things like this though. https://github.com/johnnysprinkles/kit/commit/963f0471184c245799744de7befa4ac85e82c56d
2. Make the primitives of the SSRRoute data available in the client somehow, maybe via singletons and $app/navigation, so they can parse the window.location themselves to get path params. Fewer changes in server/page/render.js https://github.com/johnnysprinkles/kit/commit/e83bd2151d55a0561c260b073358d4490067bf09
3. Maybe just add a simple hack that navigates to the current page, to get the page store to update? The downside of this is now we depend on the client router, which I wasn't planning to use. This seems like a non-starter.
4. Add two more fields into the page store, "routePattern" and "routeParamNames". For people who use client-side routing, this should update as you navigate around, even though I can only see it being useful on the first page. Now you can look at the route param values and if any seem dynamic (have colons, square brackets, or whatever convention you want to use), you can parse the path params from the URL yourself. This seems like the most correct way to go.

[benmccann]

I'd proposed moving the parsing from built time to the runtime in #36

[johnnysprinkles]

Thanks, hadn't seen that before, let me look.

[benmccann]

You don't have to use the page store. You can just use location on the client-side. I don't think we'd want the page store on the client to be different from the page store on the server

[johnnysprinkles]

Sure, for query strings you could circumvent the page store and look at location.search, but if you're using ssr and client routing, doesn't that make a weird situation where, on initial mount you have to use location but on subsequent pages you can use the page store? Seems more consistent if they can just always use the page store.

Also, for path params, just using location wouldn't be an option because the client doesn't have the pattern or param names.

[benmccann]

The query string and host aren't available at prerender time. You have to get them from the location. It's better to make this explicit

[johnnysprinkles]

That's fine, it's just that pesky path params then. I wonder if we could monkey patch a "params" property onto the window.location object. I mean of course we could, I wonder if you think we should? That would allow "location" to give a complete, dynamic view of everything the page store would normally contain. It's kind of abusing the Location builtin, and people who use Typescript might have trouble accessing a property that's not supposed to be on Location, but aside from that seems pretty elegant to me.

[johnnysprinkles]

Though, I guess this wouldn't work for people using client routing and static ssr. They'd have to look at location.params on the first page, and $page.store.params on subsequent pages.

[johnnysprinkles]

Regarding #36, maybe that's the answer. If you need to know the path params from onMount in a static pre-rendered page (at client runtime), instead of page store or location, maybe it's routerInstance.current().params or similar. Just want to make sure this all works even for people not using client-side transitions, e.g. router: false in the Svelte config.

[johnnysprinkles]

Cleaning up a little. I was thinking of SvelteKit as a comprehensive solution that fits into your overall software architecture, when in fact it's more humble than that. Mostly just a platform to start with Svelte.