Expanded support for Svelte 5

[benmccann]

Describe the problem

Add support for Svelte 5 and runes: https://svelte.dev/blog/runes

Describe the proposed solution

At some point it'd be nice to have rune versions of the built-in stores

Maybe the types generation stuff could use some changes? @dummdidumm would know better about that...

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[ThorFjelldalen]

I tried creating a +layout.svelte.ts file, for initializing a class with $state properties in the load function of the +layout, but this generates an error:

I got around it by doing it in the +layout.svelte file instead. Is this something that will be possible in the future?

[enyo]

@ThorFjelldalen since everything in the load function will need to be serialized if it runs on the server, I don't think that it makes a lot of sense to create $state in that function.

[ThorFjelldalen]

@enyo Thank you for answering! Ah, I currently use CSR, and am not used to thinking in terms of SSR.

But would this be any different to if we were to use the writable() stores, as we do in Svelte 4? The question concerns both this specific use case, but also the general use case of $runes in sveltekit ts-files. I'd think that it may be a valid use case at least in a CSR context?

Would you happen to know if there is any documentation of best practices when using stores in a SvelteKit-app? I have a global store that is initialized by api requests, and thought that the +layout / +page load function was the natural location for this, as it is relevant to the entire application.

[madeleineostoja]

is there a rough roadmap for making runes versions of the built-in stores? Would love to give all my stores the 🔪 when I migrate to runes but the built-in ones make reasoning about a proper refactor harder

[eltigerchino]

is there a rough roadmap for making runes versions of the built-in stores? Would love to give all my stores the 🔪 when I migrate to runes but the built-in ones make reasoning about a proper refactor harder

There is no roadmap and I don't think any planning will start until a while after Svelte 5 has released.

[dominikg]

there is a fromStore helper https://svelte-5-preview.vercel.app/docs/imports#svelte-store-fromstore and you can also use $derived to dig into stores let bar = $derived($someStore.foo.bar) The most used thing is probably page data and thats available through $props, so even without sveltekit native state replacements for stores your svelte5 runes app won't have to interact with stores a lot if you don't want to

[madeleineostoja]

I wasn’t aware of the new fromStore helper, looks perfect for my use cases, thanks!

The most used thing is probably page data and thats available through $props

Could you elaborate on this one? Other than the route tied to a load function, which always had data on a prop, I didn’t think page data was available through $props anywhere else? Because that is my most used app store, but for the use-case of global data available anywhere down the tree (in components, child routes, etc)

[dominikg]

you are right, page data in $props is only available on the route itself. From my experience you can get pretty far with that, only reaching for the page store in situations where the prop isn't available (eg parent layout setting title with svelte:head to a value provided by child load) But it is also totally fine to keep using stores in svelte5. Initial support for a page state in sveltekit might land in 2.x (no promises), full advantage of svelte5 (and vite6) is going to require a new major, which is a bit further out still