Binding bug after fixing [#6298]

[fedorovvvv]

Describe the bug

After the correction #6298, it is now impossible to bind functions to an object

Reproduction

this is on 3.54.0
this is on 3.53.1

Logs

No response

System Info

System:
    OS: macOS 13.0.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 319.53 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.5.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 8.12.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 108.0.5359.98
    Firefox: 106.0.5
    Safari: 16.1
  npmPackages:
    svelte: 3.54.0 => 3.54.0

Severity

blocking all usage of svelte

[Prinzhorn]

I'm not sure this was ever supposed to work the way you're using it. If you remove test from your initial object it works as expected (const functions = {}). It also works if ComponentDeep actively changes testFunction, it will correctly bubble up.

You are passing a value down and then expect the value at the end of the chain to bubble back up for no reason. I don't think this is how two-way binding is supposed to work. Again, if either you are passing "nothing" down or you actively pass something back up, it works as expected in both directions. Anything else sounds like a bug to me. By declaring testFunction inside ComponentDeep you are giving the prop a default value in case none was passed down. But one is passed down.

Passing nothing down (the function is not defined at the top): https://svelte.dev/repl/87c1b201826d441282bf67955b8ca462?version=3.54.0

The nested component actively changes the binding: https://svelte.dev/repl/10c8319933e24aa98c879d3a878072b6?version=3.54.0

In your "broken" example you essentially have two defaults (the one inside the top level functions object and the prop in ComponentDeep) and expect the nested one to change the top one for no reason.

[fedorovvvv]

Wow, thanks for the idea!
Even if you specify

const functions = {
    test:undefined
}

Then it will work

---

But if this is the case, then nothing will come of it.
Although nothing prevents overwriting the method

const functions = {
    test() {}
}

At least it used to work🥺

[dummdidumm]

I'm not sure if the previous behavior was intended or not. Previously it made a difference if the property that's bound is considered a property (export let ..) or something else (export const/function ..). In the latter case, it's treated as "this cannot be passed down, only up", which kind of makes sense since const/function cannot be changed from the outside. Maybe we need a way to distinguish these cases.

[Prinzhorn]

I didn't know const was implemented at all, let alone with those semantics. I was hoping #5572 would come some day, which behaves exactly the opposite from what you've described (data flows only down). I've never had a use-case where I wanted bind in order to essentially "grab" a const from a nested component. That's a super weird way of doing something at runtime what could be a compile time import from a <script context="module"> export. But I guess there might be use-cases I'm not aware of.

Anyway, here's a minimal version showing the difference:

https://svelte.dev/repl/e181f2a319454adeaa4cabc0eb9e62c7?version=3.53.1
https://svelte.dev/repl/e181f2a319454adeaa4cabc0eb9e62c7?version=3.54.0

[fedorovvvv]

Here is one of the ways to use such a bind:
https://svelte.dev/repl/33b80675782f4154bb8653c5b26a09e2?version=3.54.0

But if we use an object for this (as described above), then we do not bind

[Prinzhorn]

Here is one of the ways to use such a bind:

Here's what I would use to do the exact same thing: https://svelte.dev/repl/32a6b997d4b54b90adf0eb2efbd650f3?version=3.54.0
You're basically extracting the two functions from the component instance instead of calling them as methods.

Edit:

See https://svelte.dev/docs#template-syntax-component-directives-bind-this and https://svelte.dev/docs#component-format-script-1-export-creates-a-component-prop

[fedorovvvv]

Yes, it's a wonderful scenario✨
But the problem is that there is a large amount of code in which bugs have appeared

I've fixed everything for myself, but I'm sure there are other people with a similar problem (I hope I'm not the only one🥲)

[kling90]

I think this is related, noticed that a couple of components broke for us after upgrading to 3.54.0.
We're binding a value to a component and this value can be overridden if some conditions are met, which are not essential to the issue.
If you set the exported prop to a new value in the root scope the value does not update in the parent.

Broken: https://svelte.dev/repl/a5a98cde06954e0aa8ebb163cc6952ab?version=3.54.0
Works: https://svelte.dev/repl/a5a98cde06954e0aa8ebb163cc6952ab?version=3.53.1

The value should display "bar" in both the parent and child.

[Prinzhorn]

@kling90 that's something I would 100% consider a bug and breaking that was not the intent of the fix. Svelte's reactivity is based on assignment, and there's clearly an assignment. I might actually have components like that too.

[NidMo]

I'm not sure if the previous behavior was intended or not. Previously it made a difference if the property that's bound is considered a property (export let ..) or something else (export const/function ..). In the latter case, it's treated as "this cannot be passed down, only up", which kind of makes sense since const/function cannot be changed from the outside. Maybe we need a way to distinguish these cases.

So this problem is a bug? Will it be fix? Or will a new RFC be proposed in the future to distinguish this situation?

[NidMo]

I think this is the same problem
#7474