Syntax sugar for reactive declarations

[Mlocik97]

Rendered

[Mlocik97]

I was thinking about this again (and create note for my self, You can ignore these texts for now), and it would require:

1. checking if at least one variable in reactive statement is "used", that's not problem.
2. prefixing stores will be _$myvar, that's not problem.
3. how to solve this problem:

let x = 5;
let _x = 7;
let y = 4;
$: z = _x + y;

(where _x is referencing x, or should it reference _x? not to mentoy we can have defined both x and _x in one scope)

We probably can:

1. if _x is defined, we "unuse" it, if not, we "unuse" x. // I think this is bad, as it would lead to "unexpected" and ugly behavior.
2. always make _x reference to x, and _x variable be unable to be used in reactive statement. // I like this solution
3. throw error // little agressive
4. making _variable names "invalid" for Svelte, as it has special meaning for it. // I don't want this, it would go much against JS.
5. all definitions let variable would need to be prefixed, for using it as "unused" variable for reactive statement // don't like this, because, it will make code more ugly, and IDE's intellisense rage.

I think solution 2 is really good.

So:

$: z = _x + y -> _x here will always reference x variable, that means, in result code in example will result to that, z would be equal to 9, not 11, when y = 4.

So in result, we will just remove _ prefixes in reactive statement, in compiled code, and just change, how those statements are reactive.

To point 2, I only see one disadvantage, but that disadvantage is already present by this RFC and feature in beginning, and it's "broking" actual valid code (even when I think, it's not used in any real apps).

E: when I think about having _ as reserved prefix for Svelte, it can be probably good solution, as $ for stores are reserved too. But in some cases, like callback of function, I would still like to be able to use _. So Maybe we can let it reserved only for declaring variables, but not for parameters?

[7nik]

what about using control comments? something like

let a = 1, b = 2, c = 3, d;

// do not trigger for a and b
$: { // svelte:skip a, b
  d = a + b + c; 
}

// trigger only for  b
$: { // svelte:only b
  d = a + b + c;
}

// and shortening
$: /* svelte:only c */ z = a*a + b*b + c*c;

[Mlocik97]

using comments to affects what code is produced by transpiler seems like big "MEH"... not to mentoy it's too noisy, too much characters to write. Not even better than React's useEffects...

[7nik]

I agree, I haven't seen the usage of comments to control compilers, only for warnings. But this way has a good readability and is quite clear.

Another thing I was thinking is whitelists and blacklists:

let a = 1, b = 2, c = 3, d;
// whitelist
$: (a,b), d = a + b + c;
// blacklist
$: !(c), d = a + b +c;

But here labels work only with the comma operator so this approach doesn't fit the reactive block of code.

But what if we use a lambda function to define reactive dependencies:

let a = 1, b = 2, c = 3, d;
// re-calculated d only when a or b changes
$: (a,b) => {
  d = a + b + c;
}
// do not re-calculated d when c changes
$: !(c) => {
  d = a + b + c;
}

[gtm-nayan]

Just gonna leave this here https://github.com/sveltejs/svelte/issues/6730#issuecomment-923714936 👀

[lukaszpolowczyk]

Such a random idea:

<script>
let y=1;
let z=2;
let a=3;
$(y,z): x = y + z + a;
</script>

...where overwriting the a variable does nothing. It only does an overwrite of the y or z variable.

I know that the $: syntax refers to label:, but honestly it wouldn't make any difference to me, because the reference is tongue-in-cheek anyway.

---

IMPORTANCE:

@gtm-nayan This looks cool, but it would break the code because someone might have used it in a different way before. Alternatively, something like this, with, for example, a double dollar $$:

$$: {y,z} {x = y + z + a}

To distinguish one from the other.

[dummdidumm]

Svelte 5 solves this with the runes API. Any dependencies are tracked at runtime, and you can untrack them using the untrack function. Therefore closing this - thank you for the proposal.