Bug with reactive assignments and their relative positions

[kentontaylor]

Describe the bug
If a component prop foo is modified by a reactive statement, and another property bar is intended to be reactively set when foo changes, then whether or not the bar assignment runs or not can depend on its relative position to the foo statement within the source code.

To Reproduce
REPL: https://svelte.dev/repl/ada3812c534f48b5ace26933f31fdaaf?version=3.7.1

(Obviously there are more suitable/effective patterns that could be used to implement this trivial example, but it's intent is only to distill what I encountered in a more complicated scenario.)

Expected behavior
I would expect the reactive assignments to fire consistently, regardless of their relative placement to the other statements.

Severity
Now knowing the workaround, this isn't severe -- but for any newcomers that might trip over this, (especially since the underlying cause is very subtle) it can prove quite maddening.

[Conduitry]

Svelte does try to reorder reactive statements according to their dependencies, but it can only look at the variables it can statically see as part of the $: { } at compile time. So, the compiler does not consider $: formattedDollar1 = formatDollar(dollar1); something that should be done after $: incrementDollars(clickCount);.

The instrumented incrementDollars() function does invalidate dollar1 and dollar2, but apparently these invalidations don't trigger further updates afterwards. I'm thinking that doing so might be a bad idea. Consider:

<script>
	let a = 0;
	function f() {
		a++;
	}
	$: f(a);
</script>

{a}

This doesn't currently cause an infinite loop, but it seems like it would have to in order to support something like what this issue is asking for.

My inclination is that the current behavior it something that should simply be documented better. We don't currently have a good place for these slightly deeper dives to live.

[frfancha]

@Conduitry "This doesn't currently cause an infinite loop"
And that's a bug.
It is asked to run f whenever a is changed, and f always modifies a, so that can ONLY cause an infinite loop if correctly implemented

[antony]

Closing for now, as I think we now have a reasonable place to document this and a pointer to do so, should somebody feel inclined.