Reactive declarations syntax

[mindplay-dk]

Myself and others have been very confused by the syntax used to declare reactive variables:

export let title;

// this will update `document.title` whenever
// the `title` prop changes
$: document.title = title;

$: {
  console.log(`multiple statements can be combined`);
  console.log(`the current title is ${title}`);
}

It looks like a label, so it's immediately surprising to a person who knows JS - and, as someone else noted here, it isn't actually valid JS, and will likely cause problems with future integration with TS.

Could we find a more idiomatic (to JS/TS) approach?

Since this is technically an annotation, using an actual annotation might be more idiomatic:

import { reactive } from "svelte";

@reactive
document.title = title;

@reactive {
  console.log(`multiple statements can be combined`);
  console.log(`the current title is ${title}`);
}

This clarifies the meaning/intent by actually using the word "reactive" and clearly importing this member from the svelte module.

Alternatively, doc-block annotations are a bit less explicit (since they don't reference the svelte package) but aren't entirely foreign to most JS developers, who likely know it from at least the @jsx annotation used with many other libraries:

import { reactive } from "svelte";

/** @reactive */
document.title = title;

/** @reactive */ {
  console.log(`multiple statements can be combined`);
  console.log(`the current title is ${title}`);
}

One of the things I greatly appreciate about Svelte, it how it's based on basically HTML5 and JS and for the most part feels very natural to someone who knows these technologies - departing from this by changing the meaning of existing JS syntax, in my opinion, should be avoided.

And, yes, I know that the HTML part of the syntax also changes the meaning and semantics - but this is much less surprising to anyone who's ever used a template engine, where this has been common practice for many years, on many different platforms, in many languages.

Just my opinion, but, on principle, changing the meaning of something very simple like HTML is probably much easier for most people to absorb - whereas changing the meaning of something as complex as the programming language itself, can be quite confusing and surprising.

[loilo]

Just a note here: The labels are valid JS, they have just been used incorrectly in the comment you've linked.

You cannot use a label before a keyword, so $: let someVar = ... is in fact invalid JS. That's why the Svelte docs use $: someVar = ....

Some more blather about valid JS

To be honest, that doesn't make it necessarily less confusing as that code would still create runtime errors — omitting let altogether technically makes the reactive variable global (which again it can't be because Svelte uses ES modules an those imply strict mode).

However, the syntax is still valid, and that's the main thing that needs to be preserved for e.g. editor and linter support without creating an extra compiler.

[PaulMaly]

Seems, syntax is valid.

[akaufmann]

@reactive 
document.title = title;

This is not valid JS/TS because of variable/function hoisting. There are some efforts for functions to make this possible -> proposal-function-expression-decorators.

[mindplay-dk]

Seems, syntax is valid

Huh.

I figured this would parse - but didn't expect it would run.

Two labels with the same name? Wonder what happens if you actually tried goto $ 🤔

Not that anybody uses goto in real life.

And maybe the alternatives I proposed are just as bad.

My main point was this:

One of the things I greatly appreciate about Svelte, it how it's based on basically HTML5 and JS and for the most part feels very natural to someone who knows these technologies - departing from this by changing the meaning of existing JS syntax, in my opinion, should be avoided.

If nobody else thinks that's a problem, well, that's fine - just my opinion 🤷‍♂️

[mrkishi]

If you read $: something in a file and really thought "oh, that's just a label, nothing weird going on here," then you've worked on crazier codebases than I have, heh. What about export let title? Didn't that put you off? It's also not aligned with regular js.

Don't get me wrong, I'd be all in for some custom syntax, but it'd break everything in existence. Svelte isn't backed by Facebook to reinvent js at a whim. Unfortunately, @reactive wouldn't work even with Typescript/esnext decorators since they can't be applied there, and the comments... Well, that's even less strange than the label. That I could see someone not realizing was doing something drastically different after compilation.

ps. javascript doesn't have goto, but the compiler removes the $ labels from output, anyway, so it wouldn't be possible.

[mindplay-dk]

My thought was, "oh, that's a label?! something weird going on here".

Altering the language in my opinion is just too surprising and really not my cup of tea.

But I'm not sure what to suggest except "don't", which I know isn't exactly constructive, so... 🤷‍♂️

[kylecordes]

Although there are some good things to discuss, overall following the path here would make something much less like Svelte and much more like some of the hundreds of other libraries and frameworks from which to choose. I contend that the “market” for libraries and frameworks as described is extremely dense. But Svelte is in rarified air. There are only a few contenders that work very much like it. So I am quite happy to see Svelte on its path.

(Incidentally for something that feels like it fits in the language with less “magic” but more boilerplate, I suggest a good look at Angular. While it seems that almost everyone in Svelte-land has arrived here from React oh, there are more similarities to Angular.)

[mindplay-dk]

Although there are some good things to discuss, overall following the path here would make something much less like Svelte and much more like some of the hundreds of other libraries and frameworks from which to choose

The core values that makes Svelte attractive to me were there long before these newer features.

The main thing I like about Svelte is that it's fairly simple and intuitive - in my opinion, less so with the introduction of features like this. I realize that's just my personal point of view though :-)

I suppose no one's forcing me to use reactive variables in the first place, so... Personally, I can just continue to use Svelte the same as I have in the past and ignore these new features.

If this is the direction Svelte is heading, then so be it - and feel free to close this issue :-)

[Conduitry]

I wouldn't say that this is the direction that Svelte is heading so much as saying that this is a direction that Svelte has headed. There was overwhelming support for reactive assignments and reactive statements when this stuff was being hammered out a few months ago. I really don't think that optimizing the readability of the component language for people who haven't spent five minutes looking at the tutorial should be a design goal at all.

[mgambati]

I would prefer much more something like this:

import { reactive } from 'svelte'

/**
 * Code
 **/

reactive(() => document.title = title)

Plain simple syntax, no hard pre-processing, compatible with flow, typescript or any other thing that appears on next years.

[Rich-Harris]

1. That's a lot more to type than $: document.title = title
2. It doesn't work