Binding causes extra reactive call in child

[zqianem]

Describe the bug

When a reactive statement is triggered in a child component, if another non-primitive dependency of that statement is bound to the parent component, the reactive statement will be run an extra time.

Ran into this when trying to use the Broadcast Channel API to sync bound Svelte variables across tabs. The extra call would cause infinite loops in sending messages between tabs.

Similar to #5720 but without the slot.

One workaround is to add <svelte:options immutable/> to the child component.

Reproduction

https://svelte.dev/repl/2b38363381f6400b9b9a8a870fbb7b24?version=3.55.1

Logs

No response

System Info

System:
    OS: Linux 6.1 Arch Linux
    CPU: (16) x64 AMD Ryzen 7 5700G with Radeon Graphics
    Memory: 27.82 GB / 30.74 GB
    Container: Yes
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 16.19.0 - /usr/bin/node
    Yarn: 1.22.19 - /usr/bin/yarn
    npm: 8.19.2 - /usr/bin/npm
  Browsers:
    Chromium: 108.0.5359.124
    Firefox: 108.0.2

Severity

annoyance

[Prinzhorn]

The initial double logging sounds like #5689

The double logging when clicking the button seems to be caused by x = x, can you explain the intent? If you have $: x, y, console.log('hello'); it logs once and should do exactly the same?

Edit:

Ran into this when trying to use the Broadcast Channel API to sync bound Svelte variables across tabs. The extra call would cause infinite loops in sending messages between tabs.

Same, see #6298, which is just a special case of #5689

[zqianem]

Sorry, I just edited the repro (now it's x = {...x}).

My use case was to have updates to x in the parent also trigger the reactive statement, which would sometimes update the value of x itself.

Edit:

Same, see #6298, which is just a special case of #5689

From what I understand, those issues were temporarily fixed from v3.54.0 to v3.55.0 but that doesn't seem to be the case for this issue: https://svelte.dev/repl/2b38363381f6400b9b9a8a870fbb7b24?version=3.54.0

[zqianem]

To be clear, based on #6298 (comment), this behavior isn't really a bug and instead an example of conservative reactivity. I just wanted to document the reproduction and the <svelte:options immutable/> workaround.

[Prinzhorn]

From what I understand, those issues were temporarily fixed from v3.54.0 to v3.55.0 but that doesn't seem to be the case for this issue:

You are right, but it did change the initial logging behavior (the fix was for initial binding after all)

Twice: https://svelte.dev/repl/2b38363381f6400b9b9a8a870fbb7b24?version=3.53.1
Once: https://svelte.dev/repl/2b38363381f6400b9b9a8a870fbb7b24?version=3.54.0

[dummdidumm]

This will be fixed in Svelte 5