Skip to content
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

Syntax sugar for reactive declarations #54

Closed
wants to merge 3 commits into from

Conversation

Mlocik97
Copy link

@Mlocik97 Mlocik97 commented Jul 5, 2021

@Mlocik97 Mlocik97 changed the title sugar-for-reactive-statements Syntax sugar for reactive declarations Jul 5, 2021
@Mlocik97
Copy link
Author

Mlocik97 commented Aug 3, 2021

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?

I suggest to add new feature / syntax sugar, that will not use variable for reactive assignments, if it will be prefixed with `_`, so previous code would be possible to rewrite to something like this:

```js
$: myfunction(callfuncwhenthisvarchange, _dontcallwhenchange);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should show a whole code sample including the declaration of _dontcallwhenchange, here we don't know if the _ is on the variable name or just in the reactive statement

Copy link

@coyotte508 coyotte508 Dec 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should also specify the syntax when interacting with store content, is it _$dontcallwhenchange ?

Copy link
Author

@Mlocik97 Mlocik97 Dec 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, as I wrote in comment... about declaration, it still something, we need to think about, but probably it would be good to have it only as prefix in reactive statement, means after compiled, prefix would be removed from statement, to match variable name without prefix. The only issue is, if You write callback in reactive statement, where _ prefix is used naturally. Hmm... will think about it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking more about, and what about # prefix?

@7nik
Copy link

7nik commented Mar 4, 2022

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
Copy link
Author

Mlocik97 commented Mar 5, 2022

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
Copy link

7nik commented Mar 5, 2022

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
Copy link

Just gonna leave this here sveltejs/svelte#6730 (comment) 👀

@lukaszpolowczyk
Copy link

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
Copy link
Member

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.

@dummdidumm dummdidumm closed this Nov 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants