Stores lag behind routes in SSR: intentional? #3209
-
|
I’m bitten several times by the serverside rendered lag in stores that happens when a store is set on a page, but is read by a component that's higher up in I made a minimal reproduction to show the issue:
Is this like it should work? If so: what is the recommended way to deal with this problem? I'm using stores for example to set |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
See #269 (comment) for more details about this. I think this limitation could be better documented. Probably the most immediate improvement here would be built-in support for metadata in SvelteKit, which is something we'd like to do |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your reply @benmccann! I read through that issue and if I understand it correctly, the problem with SSR store lag lies in the method of building the HTML string that doesn't wait for all stores to settle. I understand the alternative would take long to render, but to me the fact that I now need to take into account the component hierarchy in order to have an up to date store is a bit of a bummer as it diminishes the convenience that Svelte stores offered in not having to think about where a component is positioned. On the surface, building in a ‘special’ store for metadata feels a bit like sidestepping the problem; I feel like this is broader than metadata alone and I imagine that there will always be cases in which data (other than the contents of Thanks again! |
Beta Was this translation helpful? Give feedback.
-
|
The metadata would not be just for |
Beta Was this translation helpful? Give feedback.
-
|
I’ve made a deployment of the reproduction for easier viewing: https://sveltekit-store-ssr.vercel.app/ |
Beta Was this translation helpful? Give feedback.
-
|
The solution we've come up with for this class of problem is #3252. Anything added to |
Beta Was this translation helpful? Give feedback.
See #269 (comment) for more details about this. I think this limitation could be better documented. Probably the most immediate improvement here would be built-in support for metadata in SvelteKit, which is something we'd like to do