Svelte 5: $state bug with <script context="module"> and <script>

[dm-de]

Describe the bug

There is an error in $state, if $state is defined in
<script context="module">
and also used in <script>.

Instead of returning a correct value, an object is returned.

Reproduction

See function in Drag.svelte.
Comment this line out - and everything is fine.

Bug with <script context="module">:
LINK

But works with additional js file:
LINK

Logs

No response

System Info

running Svelte compiler version 5.0.0-next.45

Severity

blocking an upgrade

[svelte-kit-so-good]

You cannot export a primitive signal directly.

I'm assuming that when you don't define any state handlers that reference your defined $state variable, then it compiles to a vanilla primitive.

Edit: Yea .. so if you click the "JS output" in the REPL for Drag.svelte you'll notice export let drag = $state(false) compiles to export let drag = false when you comment out your onclick function (which references drag). When you leave onclick in, it compiles to export let drag = $.source(false).

In App.svelte if you instead output{JSON.stringify(drag)} you get: {"c":null,"f":257,"v":false,"x":null,"inspect":{}} ... Not exactly sure if that helps, but yea you should either wrap the primitive in an object or define a getter function like:

	let drag = $state(false)
	export const getDrag =()=> drag

[dm-de]

You cannot export a primitive signal directly.

This is true only for context="module", but not for *.js.svelte file.
Here is a difference, that makes no sense.

Think about store: you can define store everywhere

[svelte-kit-so-good]

I don't know what you're going on about but you cannot export primitive $state/$derived from a module, whether it be:

• context='module' script, or
• .svelte.js / .svelte.ts file

Here you can see that when you export something like $state({...}) (not $state(...)) then things work. If you try to uncomment the // count += 1 inside increment you will get an error ... since count is a primitive that you are attempting export and modify (if you don't modify, then it will export since it's being converted to a vanilla value ... not a signal).

[dm-de]

OK - I thought at first I was importing a reactive thing similar to a store, but it is more like variable.
I lost 1 hour finding out the error.

[svelte-kit-so-good]

Oh yea ... you should join the svelte-5-alpha discord and search keywords to get up to speed. Here's the FAQ section of the alpha docs as well. If you still haven't found an answer using those, then ask away in the discord!

[dm-de]

Look what is possible with Vue:
(but it is wrapped - you can modify value and use state in markup)
LINK

Look what is possible with Solid:
(but is solved different as functions)
LINK

Svelte 5 (as suggested, using helper function)
LINK

[svelte-kit-so-good]

And if you were so inclined you could recreate those functions (and Angular's) like:

function signal(initial) {
    let value = $state(initial);
    
    const signalFn = () => value
    signalFn.set = (next) => value = next;

    return signalFn;
}


function ref(initial) {
	let value = $state(initial)
	return {
		get value(){ return value },
		set value(next){ value = next }
	}
}

function createSignal(initial) {
	let value = $state(initial)
	return [ () => value, next => value = next ]
}

as evidenced by this demo

... but I do agree that there is something nice that the opinionated ways of both Vue and Solid (i.e. getter/ setter functions or .value property) means that there isn't this mental divide between primitives and non-primitives.

Personally I like the flexibility of Svelte and that it gets as close to vanilla while implementing Signals ... but I know there is some initial growing pain. It might be cope but I sorta like that I have to know there is a difference between primitives (pass by value) and non-primitives (pass by reference) ... it's a topic that is not unique to Javascript.

[svelte-kit-so-good]

Svelte 5 (as suggested, using helper function) LINK

By the way your Svelte 5 example is slightly off ... you should make sure you're in "runes mode" (add <svelte:options runes/> at the top of the component if you haven't used an explicit rune). So you would actually have to export a setter too and do something like this. You might prefer to do things the 'object way' if you have to use bind: syntax

[dm-de]

Svelte 5 (as suggested, using helper function)

I don't know why, but for my real project, code like above didn't solved it - and I switched back to store.
So for me... $state is ONLY for internal state (in contrast to Vue, Solid) and store is used for GLOBAL state.
Like before in Svelte 4.

It may make sense to encapsulate the state as described here, but I no longer see any advantages doing so.

[dm-de]

By the way your Svelte 5 example is slightly off

Thank you, I discovered this too

[svelte-kit-so-good]

By the way your Svelte 5 example is slightly off

Thank you, I discovered this too

No worries. Here is an updated version.

In regards to shared primitive state:

• converting it into some$state({...}) object is simplest when exporting from some `.svelte.js' module.
• if the shared primitive state is heavily used in some component, then I would define it in the context="module" script of that component and export handlers, a getter and a setter ... rather than turning it into an object (this is what I do for some Theme.svelte component I have)

In other cases you might find that having some modified version of ref() (in the REPL) is nice .. or indeed use Classes.

Anyways, this issue should be closed now that you got an answer (no bug). Cheers!

[dm-de]

What about Svelte docs section: pitfalls?
Specially, if someone come from other framework (Vue etc.)

[enyo]

@dm-de

Look what is possible with Vue
Look what is possible with Solid

But neither allow you to do this: Just export a state object