Add a '.noinherit' modifier

[jez9999]

What problem does this feature solve?

Vue always tries to make a child element's root element auto-inherit an attribute or event listener if it's not explicitly defined in the child with props or emits. There should be a .noinherit modifier which prevents this behaviour, in case the parent doesn't want the child to inherit the attribute/listener and only wants it to apply if the child explicitly deals with it.

In addition, if the child has multiple root-level nodes, this will prevent the "Extraneous non-emits event listeners" warning from appearing. This is particularly useful when applying an event listener to a router-view, which becomes one of many different rendered routes, some of which may emit a particular event and some of which may not. Without a .noinherit, every single component with multiple root nodes that may be rendered by the router needs to be examined for every event listened to and either given inheritAttrs:false or explicitly defined as emitting that event, even if the component actually has no intention of emitting the event, in order to avoid the warning. For instance, in the following App.vue template:

<template>
    <router-view @displaymodal="handleDisplayModal" @displaypopup="handleDisplayPopup"></router-view>
</template>

... every child component that might get rendered by the router-view would have to explicitly not inherit attributes, or explicitly define displaymodal and displaypopup as emits, to avoid the warning. What App.vue really wants to say is "if the child emits this event, handle, but if not, do nothing, and don't give a spurious warning".

What does the proposed API look like?

    <router-view @displaymodal.noinherit="handleDisplayModal" @displaypopup.noinherit="handleDisplayPopup"></router-view>

[Shujee]

This is an annoying little thing that keeps cluttering the console during debugging. Hope someone could look into it soon.

[posva]

"if the child emits this event, handle, but if not, do nothing, and don't give a spurious warning".

The warning is there to help people find problems. In this case, it warns because it's applied to too many components (all existing pages) so it's normal for it to appear more than it should.

Adding a modifier to remove a development warning would be problematic as .noinherit still reflects the same behavior as inheritAttrs: false but for a single attribute, creating other inconsistencies and confusion down the line as people might erroneously use the modifier to silence a warning they should have instead adressed.

[WesCook]

Chiming in to optimistically ask, has anybody found a solution to this warning message? It seems like there's only four options:

1. Place defineEmits() on every page that will be loaded (confusing, unsemantic).
2. Apply inheritAttrs: false to all children (has side effects).
3. Ensure every page has a single root node (overly-restrictive).
4. Just don't use Router with emits (very restrictive, encourages prop mutations or use of Stores instead).

Unfortunately none of these solutions are ideal. It seems that either this warning should not trigger when attaching to router views, or there should be a way to suppress it. You have to admit it does feel pretty sloppy to publish a web app with warnings in the console.

I do like the idea of the .noinherit modifier because it addresses the issue from the parent component, unlike inheritAttrs which requires changes to all possible children.

@posva wrote:

Adding a modifier to remove a development warning would be problematic as .noinherit still reflects the same behavior as inheritAttrs: false but for a single attribute, creating other inconsistencies and confusion down the line as people might erroneously use the modifier to silence a warning they should have instead adressed.

It doesn't seem too confusing if we document which one takes precedence. I would say .noinherit does, since it's more explicit than inheritAttrs.

As for people using it to silence warnings, I think at some point you have to give developers tools that they can make mistakes with. If a dev is reaching for a way to silence a warning, it means they've already been informed of it and made a decision. This situation with <RouterView> seems like a good example where suppressing the warning would be beneficial.

Besides, offering more control over fallthrough attributes would not be unwelcome. There's already a lot of magic happening behind the scenes, like changing fallthrough behaviour if a prop of the same name is being consumed.

Mostly I'd just like to find a solution to this warning, but @jez9999's suggestion seems like a good one to me.