Should `class` and `style` should be included in `$attrs`?

What problem does this feature solve?

What’s the rationale for excluding class and style bindings from $attrs? How else would you bind these attributes to wrapped elements?

What does the proposed API look like?

Consider this field component:

<template>
  <div class="field">
    <input v-bind="$attrs" class="field__input">
  </div>
</template>

<script>
  export default {
    name: 'field'
  }
</script>

Say I’d like to bind the field__input_error class to the <input> element when hasError is true. I’d expect to be able to do it like this:

<field :class="{ field__input_error: hasError }"></field>

But if you wanted to go with the current behavior, you could do this instead:

<template>
  <div v-bind="divAttrs" class="field">
    <input v-bind="inputAttrs" class="field__input">
  </div>
</template>

<script>
  export default {
    name: 'field',
    computed: {
      divAttrs() {
        return this.$attrs.class
      },
      inputAttrs() {
        const { _, ...attrs } = this.$attrs

        return attrs
      }
    }
  }
</script>

I would suggest that we don’t overwrite existing class and style attributes as is currently done with other attributes. Also, inheritAttrs would ideally prevent class and style attributes from being passed to the root element when set to false.

[dudo]

Can this be reopened? If we can have the freedom to attach $attrs to the element we want, why can’t we be given the same freedom for $styles?

[ianef]

This has been causing me grief too, I’m having to use props with un-obvious names to pass class attributes down to my reusable components.

yyx990803 you stated “When authoring components, I don’t think it’s a good idea to encourage the user to directly style the component via classes or inline styles.” But in my mind the whole point of making reusable components that are flexible is that they can be styled by the container, thus making them easy to use without refactoring every time you want to change say the background colour or text size.

Just the name of the property ‘inheritAttrs’ should imply exactly that, maybe it should be renamed ‘inheritMostAttrs’ that way new users would get a clue!

Having to write computed properties in 90% of my components to deal with applying classes and styles to the inner elements is quite frankly very annoying and wastes time when you forget.

Personally I think the default behaviour should be changed to exclude all attributes if the flag is false, however this would now be a breaking change so how about a related property ‘inheritStylingInAttrs’ which would default to false and not include them, setting it to true would force the behaviour we are all looking for and would have expected in the first place.