Attribute Fallthrough Behavior about core HOT 13 CLOSED

@Akryum

It's unclear to me what cloneVNode does exactly :(

It clones the VNode :) The 2nd argument to cloneVNode is optional. It means "clone and add these additional props". It serves a few purposes:

• Avoid mutating the original VNode
• Handles special merging logic for class, style and event listeners

We should definitely be able to declare events just like we do with props and remove them from $attrs

What about a new option called emits? (to differentiate it from the old events option)

export default {
  props: ['foo'],
  emits: ['click']
}

I believe we've had similar feature requests in the past, but we did not implement it because we felt it didn't provide enough value. Now this would serve a few useful purposes:

• Declared events are removed from this.$attrs to avoid conflict
• Documents what the component emits - maybe can be used by Vetur for autocompletion? /cc @octref
• Enable runtime validation of required event listeners / payload type check

from core.

@posva

if $attrs contains onListeners, if you do

, we are binding a dom property onClick (which doesn't exist) to the div

That's what I mentioned in the "Unresolved questions".

is v-bind going to handle onAttribute properties automatically as events?

Yes. This is not really a breaking change since attributes and props need to be nested in 2.x. You can still declare props named onXXX and they will be removed from $attrs.

from core.

• It's unclear to me what cloneVNodedoes exactly :(
• We should definitely be able to declare events just like we do with props and remove them from $attrs, otherwise this may be very confusing. Also typically you want to customize some events behavior in a HOC and re-emit them as custom events, so some it would be even more useful.

from core.

What about a new option called emits? (to differentiate it from the old events option)

Being able to declare slots in the same way could similarly help with automatic doc generation and autocompletion. But on its own perhaps that's not enough added value to be considered?

from core.

I believe we've had similar feature requests in the past, but we did not implement it because we felt it didn't provide enough value.

There's even a current RFC proposal for such an option

from core.

There's also the topic of custom directives used on components. those also don't work anymore (or atleast don't make sense anymore), since we now have Fragements support and there's no guaranteed root element.

Were should we document this? Here? or in #29 ?

from core.

Aren't directives going to take VNodes now instead of an element?

from core.

If so I missed the memo ... :-P

from core.

#2

Now are internally on-vnode hooks with the exact same lifecycle as components

Maybe I misinterpreted that

from core.

The implicit behavior is convenient in cases where it works, but can be confusing in cases where it doesn't

Whereas I agree with that, isn't automatic inherit still the most common case (except for multiple children). When developing components in apps, I won't add the v-bind="$attrs" until I have the need to add a custom class or attribute, so I will have to check if it's already there. Whereas I almost never find myself in the opposite situation: the component picking up something I didn't want to.

How are on* events going to work exactly? Are we going to bind to the on* dom attributes directly? Isn't this a deprecated practice in favor of addEventListener?

from core.

@LinusBorg @KaelWD

There's also the topic of custom directives used on components.

That's a good point. Yeah I don't think it makes sense anymore.

The directive API is indeed going to change so that will be another RFC.

@posva

Whereas I agree with that, isn't automatic inherit still the most common case

I think explicit is better than implicit here. It's simply impossible to keep it consistent with the implicit behavior. When fragments become available, it is very inconsistent if the user have to add v-bind="$attrs" based on whether the template has one or multiple root nodes.

How are on* events going to work exactly?

v-on:click is compiled to onClick and then handled by the renderer as addEventListener('click', ...). In addition, when a component calls this.$emit('foo') will fire the onFoo handler on the component vnode if there is one.

from core.

I also prefer explicit. I think the implicit behaviour here is something a lot of users like, so I want to be able to explain correctly.

v-on:click is compiled to onClick

I meant that if $attrs contains onListeners, if you do <div v-bind="$attrs"/>, we are binding a dom property onClick (which doesn't exist) to the div. Or is v-bind going to handle onAttribute properties automatically as events? (Which would be a breaking change)

from core.

Published: vuejs/rfcs#26

from core.