Proposal: Introducing more $ sugar to reduce boilerplate like .current?

[CNSeniorious000]

When I exports something from a .svelte.js file, I always need to wrap it with code like this:

let value = $state()

export default {
  get current() {
    return value
  }
  set current(newValue) {
    value = newValue
  }
}

And accessing it became:

import value from "...svelte.js"

value.current = ...
console.log(value.current)

I wonder whether we can provide some sugar like the store syntax? Like, so that we can use $value like a normal store.

What I mean is basically provide a new rune - let's name it $wrap - then inside a .svelte.js file, users can export default $wrap(value) where value is a $state().

And user can access it via import value from "...svelte.js" and use $value like using a store!

I think this way is easier than using getter and setters.

[CNSeniorious000]

Another example, I think

<script>
	import { innerWidth, innerHeight } from 'svelte/reactivity/window';
</script>

<p>{$innerWidth}x{$innerHeight}</p>

is better than:

<script>
	import { innerWidth, innerHeight } from 'svelte/reactivity/window';
</script>

<p>{innerWidth.current}x{innerHeight.current}</p>

I think providing best DX with performant reactivity is one of Svelte's goals.

People don't like Vue's .value and Svelte used to provide much better DX, that's why people prefer Svelte over others. But .current is just like .value.

[brunnerh]

I do not think this will be changed.

The definition does not need to be that complicated:

export const value = $state({ current: undefined });

(If you really want to, you can transform $state into a store, but you will lose fine-grained reactivity. Also, stores are supposed to be faded out in favor of using $state, so adding more is not really a good idea.)

[CNSeniorious000]

Yeah. I fully understand what you mean. In fact I am not prefering the store, but suggesting that we can support a new sugar which use $ for unwrapping { current: ... } boxes. Maybe it would be a good idea after Svelte 6 (at that time store will be removed and the $... syntax would be free to redefine!)

Or to say, I really prefer runes over states, but think boilerplates could be removed with some syntax sugar! Why not! Svelte is known for its compiling process, so why not add more sugar to reduce boilerplates?

A clearer proposal

New syntax

import { foo } from "some-module.svelte.js"
$foo = 123
console.log($foo)

can be transformed to:

import { foo } from "some-module.svelte.js"
foo.current = 123
console.log(foo.current)

And typescript can raise a typeerror if foo is not a { current: T }

New runes

$wrap

bar is a $state

export const bar = $wrap(bar)

compiles to

export const bar = {
  get current() {
    return bar
  }
  set current(v) {
    bar = v
  }
}

And there could be an $wrap.readonly alternative to only compile the getter.

$unwrap

let bar = $unwrap(barwrapper)

compiles to

let bar = $state(barwrapper.current)
$effect(() => barwrapper.current = bar)

---

Of course, these are just some of my random thoughts—not particularly serious proposals, but hopefully somewhat thought-provoking. Personally, I’d love to see more “magic” in Svelte 5 because compile-time features don’t have runtime side effects (I mean, they don’t increase the runtime code size, so I don’t see much downside).

[brunnerh]

Maybe it would be a good idea after Svelte 6 (at that time store will be removed and the $... syntax would be free to redefine!)

That would work from a technical standpoint but could cause confusion. Old codebases with stores are probably going to stick around for a while and writings on the topic as well. I doubt that the maintainers consider this a viable option.

[t1u1]

That would work from a technical standpoint but could cause confusion. Old codebases with stores are probably going to stick around for a while and writings on the topic as well. I doubt that the maintainers consider this a viable option.

In that case, could use a slightly different syntax like $$ or some other special escape character.

[Ocean-OS]

$$ is already used for Svelte internals, and I don't think we need any more prefix syntax, as each addition restricts more and more variable names.