Attr fallthrough behavior

[yyx990803]

This is a follow up of #26, but with much less breakage.

• Make the attrs fallthrough behavior more consistent;
• Make it easier to pass all extraneous attrs to child elements / components.

Rendered

[tmorehouse]

For class and style bindings, and inheritAttrs is false (or implied false), how would one make the style/class binding apply to the root element, but not the inner element?

<template>
  <div :class="$attrs.class" :style="$attrs.style">
    <!-- How does one easily prevent style and class from also being applied here? -->
    <div v-bind:"$attrs">
       Foobar
    </div>
  </div>
</template>

Perhaps there needs to be similar flags for inheritStyle and inheritClass?

[Meekohi]

For class and style bindings, and inheritAttrs is false (or implied false), how would one make the style/class binding apply to the root element, but not the inner element?

Specifically, you may often wish to apply all event listeners to a child element... maybe a simple helper that plucks off the listeners from $attrs would cover most cases? v-bind:"listenerProps($attrs)"?

[yyx990803]

@tmorehouse you can create a computed property based on $attrs, in which you can pluck off anything you don't want to pass down to the inner element.

[tmorehouse]

@yyx990803 so something like this could be done to omit style/class:

export default {
  props: {
    foo: { type: Boolean, default: false }
  },
  computed: {
     computedAttrs() {
       return { ...this.$attrs, style: null, class: null }
     }
  }
}

Although is this.$attrs reactive (to trigger the update of the computed prop)?

Similarly, if one wanted the v-on listeners (which are now top level onXXX properties in $attrs), one would need to use a bit more convoluted code to eliminate the listeners (or extract the listeners) so they can be targetted to another element:

export default: {
  computed: {
    computedListeners() {
      return Object.keys(this.$attrs).reduce((obj, key) => {
        if (/^on[A-Z]/.test(key)) {
          obj[key] = this.$attrs[key]
        }
        return obj
      }, {})
    },
    computedAttrs() {
      return Object.keys(this.$attrs).reduce((obj, key) => {
        if (!/^on[A-Z]/.test(key)) {
          obj[key] = this.$attrs[key]
        }
        return obj
      }, {})
    }
  }
}

Perhaps exposing a few utility methods like omit(obj, keysArr) and pluck(obj, keysArr) might be useful.

[yyx990803]

@tmorehouse it does remind me that $attrs is not reactive and a simple method call is probably more consistent. (Maybe we should make it reactive? It's a matter of cost vs. benefits)

As for helpers like omit and pluck - these are generic JS utilities and there are already plenty of existing libraries out there, and it doesn't really take much effort to write yourself (they can be easily tailored to your specific needs and reused across your project). Vue will only provide helpers that are Vue-specific.

[michaeldrotar]

this probably isn't the best approach, and I haven't Vue'd in almost a year so I'm sure I have some syntax wrong.. but could you do something like this?

<!-- search-component.vue -->
<template>
  <form v-bind="$attrs.form" @submit="search">
    <input type="text" v-bind="$attrs.input">
    <button type="submit" v-bind="$attrs.button">
       Search
    </button>
  </form>
</template>

Usage:

<search-component
  input="{ name: 'foo', value: searchText }"
  form="{ onSubmit: fancySearch }"
/>

[leopiccionia]

@michaeldrotar I think it should be <search-component :input={ ... } :form="{ ... }/>, to bind an object instead of a string. But I think that registering a prop, in this case, would be more idiomatic than using $attrs.

[cjpearson]

Does this also affect v-slot props? Would listeners be exposed as onXXX props there?

[yyx990803]

@cjpearson yes.

[yyx990803]

This RFC is now in final comments stage. An RFC in final comments stage means that:

The core team has reviewed the feedback and reached consensus about the general direction of the RFC and believe that this RFC is a worthwhile addition to the framework.
Final comments stage does not mean the RFC's design details are final - we may still tweak the details as we implement it and discover new technical insights or constraints. It may even be further adjusted based on user feedback after it lands in an alpha/beta release.
If no major objections with solid supporting arguments have been presented after a week, the RFC will be merged and become an active RFC.

[tmorehouse]

I still like the idea of $listeners which pre-separates events from attributes to make it easier for plucking out event handlers instead of creating wildcard RegExp's to find anything that matches /^on[A-Z]+/

Perhaps instead of $attrs having everything, maybe a new property $all would have everything, and then $attrs is any non event, and $listeners has only events.

This would follow more closely the template convention of @xxx for events, and :yyy="expression" (or yyy="string") for attributes/props. unless instead event handlers will be placed on elements/components as :on-foo-event="handler" (requiring the v-bind so that a handler reference can be passed)

[yyx990803]

This proposal has been replaced by #137.