-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Runes: use $ prefix in variables to denote signals #9401
Comments
What happens when you don't want |
don't add Or a more explicit version: let $name = 'Alice'
let $lastName = 'Black'
let $fullName = `${$name} ${untrack(() => $lastName)}`
console.log($fullName) // => 'Alice Black'
$lastName = 'Brown'
console.log($fullName) // => 'Alice Black'
$name = 'Bob'
console.log($fullName) // => 'Bob Brown' |
The
Also, you can remove whitespace and new lines to shorten your code even more. Less code does not always make the code more readable.
It still will be possible to create such fields/methods/functions that, in fact, are reactive, or it depends on whether a passed and internally used value is reactive. So, the extended pros and cons are: Pros
Cons
Another big problem it creates is misaligning with the |
I thought a lot about this feature. I was against it at first, but I think it's actually a good idea. There are actually two ways to do it:
Example 1: <script>
let $counter = $state(0)
</script>
{$counter} Example 2: <script>
let counter = $state(0) // here we don't prefix with '$'. Instead, we define `counter` as a reactive variable.
</script>
<!-- Now, we use the $ prefix operator to indicate we want to retrieve the reactive value -->
<!-- That would simply transpile to `$.get(counter)` -->
{$counter} To me, solution 2 is the cleanest, as you are working with the true values. There is only 1% magic, which is the $ prefix operator for some sugar syntax. The con of the syntax 2 is that it demands some work to make it work with Typescript compiler. It's not impossible, though, as it has already been done with the old store syntax. Adopting such a solution would have two great advantages: 1. ReadabilityIt has the advantage of increasing readability. You know if a variable is reactive or not, just by looking at it. Not the most important, but still nice. 2. Solving the issue of these annoying gettersI think the getters are the biggest issue in runes right now. Everyone agrees that's the syntax is very boilerplatey, which is the opposite of what Svelte stands for. When you create an external reactive variable, like this: export const counter = $state(0) <script>
import { counter } from "./counter.js"
</script>
{counter} This does not work because the Svelte compiler does not know that counter is a reactive variable. How could it know? You have to get to the type of the variable to be sure that we are handling a reactive variable. However, with a <script>
import { counter } from "./counter.js"
</script>
{$counter} It's somehow similar to the old store syntax and the Vue 3 syntax. What is awesome is that the syntax works very well with signal's fine-grained reactivity (which would not work with stores): // we have a plain object that has a reactive value
const counter = {
value: $state(0)
} <script>
import { counter } from "./counter.js"
</script>
{counter.$value}
<!-- That would transpile to `$.get(counter.value)` --> ConsAbout the forementioned cons:
If you keep the
It's not an issue with syntax 2.
It's an issue that should definitely be solved by adding the following shortening:
As for What do you think? |
Well, you are free to name variables as you want.
It won't work correctly in |
Of course I'm free to prefix my variables as I want, but the idea is to get rid of the "getters problem". Which is, to me, the single biggest issue of runes right now.
Indeed, if there is no way to do so, it would prevent stuff like that:
Two solutions:
|
No, it wouldn't. Definition of svelte/packages/svelte/src/main/ambient.d.ts Lines 17 to 18 in 37f2493
It's just that the svelte compiler treats |
I was not talking about $state but about the two syntaxes We are defining a variable This is an issue that happens with syntax #2 only. I you had prefixed your reactive variable with a |
I updated list of pros and cons in the top comment. I am pretty sure that all cons heavily outweigh the pros. But I still wish there was a more concise way to denote a reactive state and derived state. It's too verbose and I don't like that it's inside parenthesis. let x = ...
$: x = ... is so much simpler than let x = $state(...)
let x = $derived(...) |
By the way, the "getters problem" is not a problem anymore with the new proxy system :) I agree to close this, it was interesting to talk about this subject! |
Describe the problem
Since runes are to be available only in
.svelte.js
and .svelte.ts
files, so they will be ignored in any other.js
or.ts
files, why not omit$state
and$derived
runes entirely and replace them with$
prefix in variable names.Describe the proposed solution
will become
Pros and cons
Pros of
$
prefix:let $x = ...
is 7 characters shorter thanlet x = $state(...)
and 9 characters shorter thanlet x = $derived(...)
$
prefixCons of
$
prefix:$
in the variable name makes it reactive.$state
and$derived
are explicit and may be easier to understandlet { param } = $props()
.param
is not prefixed with$
but it IS reactive.<Comp param={$param} />
$name
instead ofname
field. This may be a con but can also be a pro, so consumer of theUser
class can clearly see that the$name
is reactive.Alternatives considered
-
Importance
nice to have
The text was updated successfully, but these errors were encountered: