cannot use 'in' operator to search for "__vInternal"

[oliverpool]

Version

3.2.3

Reproduction link

https://sfc.vuejs.org/#ey...

Steps to reproduce

I have made a component, which has a with a v-bind:

    <slot v-bind="option" />

When the "option" variable is a string, it throws an error with vue 3.2.3 (it worked just fine in 3.1.5).
If option is an object, everything works fine.

What is expected?

<slot v-bind="option" /> should work if option is a string.

What is actually happening?

<slot v-bind="option" /> throws an error:

TypeError: cannot use 'in' operator to search for "__vInternal" in "text of the option"

[Bigfish8]

I dont think this is a bug.You should guarantee 'option' is an object here.

[LinusBorg]

It's definitely not documented usage, but worked in 3.1.5.

Conceptually/technically, it make some sense, as the slot content is a function receiving an argument, which could just be a string or any other type of value, there's not technical limitation saying it has to be an object on that end.

So we could argue that a v-bind (without an argument), when used on a <slot />, can accept not just objects but any value, but that would make v-bind usage here different from using it on components, which might lead to confusion.

I'd rather have a pattern where slot props from v-slot are always an object, and consequently, v-bind on a <slot /> always has to be passed an object, like v-bind on a component.

From that POV, the 3.1.5 behaviour was an unintended side-effect of the implementation that was cleaned up in 3.2 - but then we should see if we can give a better error message than this raw JS error.

[oliverpool]

You should guarantee 'option' is an object here.

You are right, I just saw on https://v3.vuejs.org/api/directives.html#v-bind:

Expects: any (with argument) | Object (without argument) (my case is without argument, so it must be an object).

---

I fixed my code like this:

    <slot v-bind="{ option }" />

  <RadioInput
              ...
              v-slot="{ option: distance }"
              >

---

we should see if we can give a better error message than this raw JS error.

That would be very nice if it is easy to implement (I struggled quite a bit to identify the actual bug after the upgrade).
However since no-one else seems to have make the same mistake as myself since the 3.2 releases, I don't think that it is worth spending too much time on this (hence I will close this issue).

Thank you for your quick support (and this great framework :-).