Reactive declaration on a store, caused by a change in another store from another component is not called

[lovetoast]

Describe the bug

ComponentA setting the value of a store (call it store1), which calls a function in ComponentB as it is dependent on this store. The function in componentB sets the value of another store (call it store2) and has a reactive declaration for store2 (just a console log, or anything else for that matter), the reactive declaration is NOT called.

This appears to be because the initial trigger is from ComponentA. If I update store2 from ComponentB, it calls the reactive declaration on store2.

To Reproduce

Please click here:

https://svelte.dev/repl/f51251e28e1a42d292de15b1a6079476?version=3.24.1

Top.svelte sets setCategory (type the value in the text field and hit SetCat and it updates it). Annoying.svelte listens for this and calls on onSetCat, which console logs (to make sure it's running) and then sets setSearch, which should show an alert, but it does not (only shows on page load, when the value is set from stores.js. There is a button in Annoying.svelte, called try locally, and this DOES trigger the reactive declaration. I've included commented code for a traditional subscribe function, to show it does not work with this either.

Information about your Svelte project:

• Version 85.0.4183.83 (Official Build) (64-bit)

• Windows 10

• Reproduced on repl which I believe is the latest?

Severity

Umm going to be honest, I like this bug, because it actually makes my live search function work a bit better, but hey, I'm an honest guy.

[lovetoast]

Though:

https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_reactivity_lifecycle_accessibility

This appears to imply that Svelte will wait for the next process?

[bfanger]

A more visual REPL demonstrating the issue

[bfanger]

The ordering inside the compiled $$self.$$.update = () => { function matters, a minimal example:

<script>
  let amount = 2
  let price = 1.99;
  let total = 0

  $: formattedTotal = total.toFixed(2)
  $: calculate(amount) // $: calculate doesn't work when placed below the $: formattedTotal

  function calculate(n) {
    total = price * n
    console.log('calculated '+ total)
  }
 </script>

{price} x <input type="number" bind:value={amount} /> = {formattedTotal}

REPL

This makes the reactivity system unreliable, i'll see if I can fix the issue or provide a meaningful warning message.
It's quite tricky as I don't want to allow circular dependencies.

[lovetoast]

The ordering inside the compiled $$self.$$.update = () => { function matters, a minimal example:

<script>
  let amount = 2
  let price = 1.99;
  let total = 0

  $: formattedTotal = total.toFixed(2)
  $: calculate(amount) // $: calculate doesn't work when placed below the $: formattedTotal

  function calculate(n) {
    total = price * n
    console.log('calculated '+ total)
  }
 </script>

{price} x <input type="number" bind:value={amount} /> = {formattedTotal}

REPL

This makes the reactivity system unreliable, i'll see if I can fix the issue or provide a meaningful warning message.
It's quite tricky as I don't want to allow circular dependencies.

Hi Monsieur Bob, thanks for your reply, but, I may have been mistaken, is this not a bug at all and instead how svelte handles the micro-processes?

PS I was just reading a stack-overflow answer on Svelte, from last month regarding #key and I was thinking this sounds weird but awesome, I'm hoping it was written by an authority, and hey, it was you!

[bfanger]

Definitely a bug. when you write:
$: formattedTotal = total.toFixed(2)
it shouldn't matter if it's at the start or at the bottom of the script tag, that should just work.

I do expect resistance to a solution. That will need some iterations to get right.

[guidobouman]

Another repro in the REPL:
https://svelte.dev/repl/8180d687add34e76b57d5b98508154b0?version=3.31.2

As you can see, the moment a function is defined reactive with a parameter, it does not trigger any subsequent reactive updates. While executing the function the moment the initial reactive variable is changed does trickle down all subsequent changes.

[guidobouman]

@bfanger Maybe change the title of this issue to reflect the actual bug?

[bfanger]

@guidobouman I did not report the issue, I did figure out why it happens and created an RFC which outlines a possible solution.

[dummdidumm]

Both the REPL by @guidobouman and the issue outlined in the RFC by @bfanger are actually expected behavior given how reactive statements currently work. The key is that the code is analyzed beforehand and only the values immediately part of the declaration are taken into account for ordering. This is explained in more detail in this issue and this section of the community docs. The latter also explains why this behavior actually is desirable for some people because you might want to hide specific values from reactivity tracking.

[guidobouman]

@dummdidumm
Okay, we can shield a variable from reactive tracking with a function. But what if, in a function, you edit a variable that is used by another reactive variable? Then the reactivity breaks when the order is not correct. The compiled code from my example showcases this: $$invalidate() is compiled into the function.

This does not seem like intended behavior. Especially when it starts working the moment you change the order of the reactive declarations.

[dummdidumm]

This at the moment is the intended behavior, because as described in the issue linked above, you hide the variable from the ordering algorithm because it's inside the function. You need to make it a direct dependency of the $-statement like $: activeVideoKey = switchToIdle(targetState);. The reactive algorithm does not look into functions referenced in $ to determine the order.

[guidobouman]

For my understanding: Then where does the $$invalidate around the reactive var inside the function come from? 🤔

If the compiler adds the $$invalidate method, then I would expect this part of the linked comment to also become true:

For example, if one block updates foo and another uses foo, the block that updates foo will end up before the other one in the compiled code, even if it were second in the component definition.

[dummdidumm]

The $$invalidate and the ordering of the reactive statements are not related to each other. The sentence in the linked issue explains it: "In your component, the compiler cannot tell that the second reactive block might cause changes that should cause the first block to be re-run, because the updates to activated (in your case activeVideoKey) are hidden in the activate() (in your case switchToIdle) function. So it defaults to keeping them in the order you wrote them"

[guidobouman]

Okay, $$invalidate and the reactive statements sorting are different and unrelated. But can the dependencies not be tracked through the same mechanism that adds the $$invalidate calls? Maybe to influence the sorting or otherwise to improve the reactivity.

I hoped that the $$invalidate call, that is wrapped around all reactive statements, could be used to make this work.

---

PS: The RFC explains the issue nicely:

Svelte reactivity system is invisible, even considered "magic", when it doesn't work as expected, it's very hard to debug.

In the current implementation, reactive statements are not always run or are not run with the latest values, this depends on the ordering inside the generated code [...]