[opensas]

> The $ label is one technical reason why I would be hesitant to adopt Svelte for larger projects. It's a core part of Svelte that you can't always avoid, and I think the potential for introducing bugs through it is high to start and very high at scale.

The reactivity system in Svelte is really a joy to use, once you get used to it there's no turning back.

But the author did hit one of the ugliest pain points about it. Svelte can NOT correctly infer transitive dependencies when the variable being updated is inside a function. Meaning that the variable itself will be reactive (it will be invalidated every time it's assigned, even inside a function) but Svelte is not using that information to build the dependency graph, and falls back to the order in which the reactive blocks were defined, which may or may not be right.

I created this issue https://github.com/sveltejs/svelte/issues/5190 a couple years ago documenting it.

It's not so common, but when it bytes you it's pretty nasty.

The workarounds I found are the following

These are the workarounds I found:

- a repl with the issue: https://svelte.dev/repl/640736d3c91d40d3971afcc3eef8b25e?ver...

- workaround 1: manually reorder statements, need to figure out by yourself (and maintain!) the dependency graph: https://svelte.dev/repl/3ecd6aa918e045999db32d379270fc1c?ver...

- workaround 2 (my favorite): provide a redundant update as "hint" to tell the compiler that setY updates y: https://svelte.dev/repl/cbf98bb35f5e4dd4b037d13254853c90?ver...

(thanks to TylerRick for this: https://github.com/sveltejs/svelte/issues/5190#issuecomment-...)

in practice it means to do something like: `$: { setY(x); y = y };`

- workaround 3: put the update operations in order in a single block (it's just the workaround 1 with improved legibility, IMHO): https://svelte.dev/repl/074df362bb934312bbe6fd3aeccab771?ver...

I still think we could do better, at least explaining the issue and how avoid to fall into it (perhaps some linting warning?)

But I really hope svelte developers start considering this an issue to solve, it's inconsistent (meaning the variable is reactive but that reactivity is not taken into account to order the operation in "topological order" (Hey, I learnt about that from one of Rich's presentations, see https://rethinking-reactivity.surge.sh/#slide=19) and as I said before, in the rare occasions you stumble upon it is not so easy to understand what's going on.

[pcthrowaway]

Interesting, my memory of reading about the Svelte magic reactivity was that it was pretty well explained that the only things 'reactive' would be things which were assigned to in the reactive statement.

So if you want to update y on some changes to x, you do

    $: y = x

And if you need something more complicated, a transformation perhaps, you put the logic in a function and assign y to the result of that

    function parseX(val) { ... }
    $: y = parseX(x)

[opensas]

top level variables are reactive even when updated inside a function, just give it a try:

https://svelte.dev/repl/44e3aece18294ddb834bcdfb4394af48?ver...

` <script>

  let name = 'world';

  const flip = () => name = name === name.toUpperCase() ? name.toLowerCase() : name.toUpperCase()

  $: console.log({ name })

</script>

<h1>Hello {name}!</h1>

<button on:click={flip}>flip!</button> `

[opensas]

the inconsistency comes from the fact that this reactivity, triggered from inside a function, is not taken into account to build the dependency graph and ultimately decide in which order to process the statements