Page variants selected based on `URLSearchParams` and/or cookies

lukaszpolowczyk commented 2 years ago

Describe the problem

Currently, if any elements on the page depend on URLSearchParams and/or cookies, they must be rendered every time, with every request from the user. Even though they sometimes differ in only a few small things, on an on/off basis.

Describe the proposed solution

It would be nice if it would be possible to enter in the route, for example in load, several variants of the same page, so that it would load already ready, and not rendered every time.

I don't have a ready idea how to write different variants.

But the readout (also not very well thought out) is probably the best:

in load read URLSearchParams and/or cookies,
use a function such as variant() and pass parameters/cookies to it,
if there are such parameters in the stored variants, that variant is returned.

Wise heads would surely find a better way, if they found it worth building into SvelteKit.

Alternatives considered

Only rendering with each request from the user.
Separate pathname for different variations of the same page.
Manual server configuration, which would have to be done outside of SvelteKit, bypassing SvelteKit.
Introduce a "CSS Cookies Media Query" - A non-existent query that would avoid blank page and blinking. (also standard for URLs, like @-moz-document url-prefix("https://github.com/"))

Importance

would make my life easier

Additional Information

No response

CaptainCodeman commented 2 years ago

I'm not sure, but it sounds like you might want to just move the data fetching up to a layout so it stays constant while those params change. I have something similar where there are some product variations that go in the searchParams, but the product info only loads once and they just point to which chunk of data to use within it.

lukaszpolowczyk commented 2 years ago

@CaptainCodeman Let me give a very simple example.

<!-- +page.svelte -->
<div hidden={comeback}>first visit popup</div>
<div>content</div>

And when the cookie comeback=true, then in SSR the div with the popup disappears, already on the server side. Nothing blinks on the user side.

And I think you can see the blinking even more when you have to use {#if}.

So you have to use SSR so that nothing blinks. You can't use prerender, because there are two variations of the page:

first visit
comeback

If you were to introduce a page variant function, you could render two page variants ONE TIME, and never do it again. for each user, each time.

It's not as static as prerender, but it would be very similar. On the server side, only URLSearchParams and/or cookies would be checked, and that would be it. There would be no need to render both versions for each user, with each request.

This can be treated as two completely separate pages, just under one pathname.

CaptainCodeman commented 2 years ago

Personally, I'd put something like that in the page head block, to set a class or css property that can show or hide things. That way every page is identical for every user, but they can see different things based on some local preference (exactly the same as how TailwindCSS dark mode works).

But if your aim is to avoid the render on the server, you probably want some form of output caching where that parameter makes up part of the key (so once the two versions are rendered, they don't need to be re-generated). Unfortunately, SvelteKit currently makes output caching a bit harder than it needs to be because of where it handles the conditional 304 response so you have to mess about with the headers to achieve it.

Honestly though, it's not going to be a lot for the server to render a class or attribute based on something in the request.

sveltejs / kit