-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix the content flash problems with contexts #2
base: main
Are you sure you want to change the base?
Conversation
I tried to learn as much as I could from your issue, this PR and blog post and I have to ask one thing. Why is |
SSR is kind of the whole point of using SvelteKit. It massively reduces the time to load the initial page: instead of serving a blank HTML page and then the needed content is loaded from the browser (thus the user seeing a bunch of spinners and other loading indicators). With SSR the server page is already fully complete, nothing needs to be loaded asynchronously anymore. |
Ah, so |
Right, without SSR you could always use a writable store and have none of the problems. |
Other frameworks sandbox each server-side render of apps. Using the node VM Module |
Today I've learned about this issue the hard way: When using SSR, you have two stores, one on client and server. if you hit F5, server store remembers old values while client one is reset as I would expect: This code is on some svelte page:
The store is a simple: Now if I execute this, and do F5 on the page, on svelte-kit console I see "count 1, count 2, count 3...", but on browser console "count 1, count 1, count 1..." which is the desired behavior on a full page reload. The point of SSR is to execute the same code on server and on client, and this breaks coherence between server and client, making SvelteKit SSR quite limited. Any plans to fix this? Would work if each SSR request had its own stores? |
That's probably best asked on the Svelte repo :) |
Please check out https://www.loopwerk.io/articles/2022/sveltekit-architecture/ and https://github.com/loopwerk/sveltekit-architecture for a much better version of this solution. |
Thanks for your write ups, this helped me a great deal in understanding how Svelte (and SSR in general) works. I ran into the same problem and came up with a similar solution. But I simply set the store on the client, and not in the
|
But you're always doing |
The main key takeaway from the problems I was seeing with the content (on refresh it flashes from old content to new content, and the old content is shared between browsers), is that using Svelte stores from SSR is a hard no. That state is shared across all clients, so it's just not usable.
The initial fix to simply add a check to see if we're in the browser wasn't ideal, as you'd now see content flash from "undefined" to the actual content (see also this article). By adding contexts and using either the store or the context as a fallback, I've solved all the content problems, but at the cost of considerable boilerplate.
The problem where after login the header wasn't updated also fixed itself.