Unexpected Reactive Variable Triggered

[Ncookiez]

Describe the bug

When using a <select> element with its value binded to a variable, any references to reactive variables as values within an <option> element will unexpectedly trigger an update, even though no assignment was made.

Reproduction

Example 1: https://svelte.dev/repl/a050763e72284de0abbe42d28d916940

Example 2: https://svelte.dev/repl/8c9265b7a7bb4100b39df520d1b39f4f

In both examples, the variable a or a iteration of it is referenced as the value of the <option> element, but is never assigned - the console log is triggered nonetheless.

If the <select> element is no longer bound to b, the bug disappears.

The bug remains whether the <option> element references the reactive variable through value={a} or just {a} within its contents.

Logs

No response

System Info

REPL Running Svelte v3.48.0
Browser: Brave/Chrome/Edge, etc.

Severity

annoyance

[baseballyama]

Surely this may be unnecessary process, but could you please tell me the actual problem / issue of this?

In this case, I think that simply implementing const a = [1,2,3]; would solve the problem, but in practice, do you have more complex actual use cases?

[Ncookiez]

Surely this may be unnecessary process, but could you please tell me the actual problem / issue of this?

Of course - this is currently an issue when trying to update the options on the <select> element dynamically/reactively, either through a simple function or with something as complex as getting inputs from stores linked to local storage variables, etc.

A simple example:

$: options = $colors.filter(color => !$hiddenColors.includes(color));

If the $colors and $hiddenColors stores are set and manipulated in multiple places elsewhere on the app, it might be inconvenient to keep setting the options every time any of those are manipulated, or have it as a store, when this logic is simple and should likely only be there on the component that actually needs to use these options.

[daison12006013]

That's a behaviour in select's bind:value

Try to add <select ... on:change="{(e) => console.log(e)}" >, the event actually triggers each of the <option> once it changes, that means a will receive a signal that a state ping/change happened.

If you still want to apply your $: a ; then use on:change and capture the selected value as e.srcElement.selectedIndex rather than bind:value

<script>
  $: a = [1,2,3];
  $: console.log(a);
</script>

<select on:change={(e) => console.log(e.srcElement.selectedIndex)}>
  {#each a as x}
    <option value={x}>{x}</option>
  {/each}
</select>

TL;DR; ~ "intense" from discord and that's me.

[Ncookiez]

That's a behaviour in select's bind:value

I'm glad it's been narrowed down further, but surely this is not working as intended? Reactive statements should react when the variables they reference are updated. a is not being updated - therefore the reactive statement should not get triggered in this case.

I do like your workaround of using on:change instead though - will most likely change my current dirty workaround to this for now.

[baseballyama]

Essentially, the issue is that reactive statements are being executed eagerly.
Currently, this may occur because reactive statements are being called conservatively.

If such behavior is unacceptable, then you need to be addressed in the workaround like above for now.

[baseballyama]

I found the same issue at #5689.
So now I close this issue as duplicated of #5689.

If you think this is not the same as #5689, please tell me,
then we can reopen it.
Thank you!