$attrs no longer contains events declared in the emits option

[marina-mosti]

As a follow up to vuejs/core#4736

It would seem that it would be a good idea to open up discussion as to whether or not there should be a way to declare somewhere in the component that $attrs should maintain onX listeners even when they are declared in the emits option of a component.

In many cases, a component that extends a sub-component will both want to pass down listeners through v-bind="$attrs" attribute fallthrough and through an $emit, which creates the conflict.

Two workarounds are suggested in the above issue, one being adding a prop that contains the expected listener/function. The other, explicitly listening for and re-emitting the event.

@posva suggests in his comment
a new option similar to inheritAttrs which could be a nice less-invasive solution to the problem.

[adamreisnz]

There is another use case, not just passing on attributes. One might want to detect if a component has a listener attached to it or not, and render a part of the component conditional on the presence of the listener.

This is currently not possible if the event is declared in emits.

The workarounds presented (e.g. specify the listener as a prop) are not conforming to best practices and break consistency in how listeners are to be defined and applied.

So we're currently forced to define additional redundant flag props to indicate whether a listener has been added.

Rather than another flag like inheritAttrs we'd just like to see an easy way to access all attached listeners to a component like was possible in the past, whether they're present in emits or not.

[jods4]

@MattFromGer
What did you do with useAttrs()? I tried it in your Stackblitz and it worked fine for me.

defineEmits isn't odd, it's actually the point being discussed in this issue.
In Vue 3, $attrs is a catch-all bag of everything that was set on component that isn't declared/known.
As soon as you declare something with defineProps or defineEmits, it is not going to be found inside $attrs anymore.

If you want to condition the button visibility on the presence of a listener, you should declare a onOnDelete prop (you have strange naming going on here by naming your emit onDelete... delete would be more sensible).
Then you can v-if=onOnDelete, and $emit('onDelete') still works.
Modified Stackblitz

[MattFromGer]

@jods4 Thanks for the clarification. I guess this issue is confusing. Anyway, I updated my Stackblitz url to highlight my issue with useAttrs()

[jods4]

@MattFromGer useAttrs is not a macro, it's a real function that you need to import from Vue.
Working Stackblitz with useAttrs

[douglasg14b]

This doesn't appear to show up when using defineProps, if I have emit & prop with the same name, the prop is never defined even when bound.

useAttrs() is also empty.

Which leads to the conclusion that this isn't possible unless we stop using new things?

[turbobuilt]

Exactly, this is a totally legitimate use case and should be added ASAP.

Further is upsets me a lot that this design decision was made from a theoretical standpoint, because every developer has the RIGHT to know everything about the data he's working with. This is intentionally denying the developer access to data about the component that should be easily accessible.

The whole point of programming is thinking outside the box. When you artificially limit the information available though - you handicap the framework. As a rule of thumb - a framework should never reduce the amount of data available to the user.

Yes it's true we can use :onEvent, but that's not the right way to do it! The only way to solve the problem correctly is to detect the listener.

[jods4]

Vue support for events (through $emit) is really as "pure pub-sub" as it gets.

Anything that deviate from decoupled pub-sub isn't available with $emit, such as:

• Finding out if there's actually a listener or not;
• Grabbing a returned value from the (last) invoked listener (you can pass a mutable argument, though);
• Accessing the event listener directly and passing it down or around (note that there could be more than one).

On the other hand, all those things are possible if you declare an onMyEvent prop instead for those cases.
Is there anything wrong with declaring a prop when one deviates from raw pub-sub?
It can even be seen as an indication that you're doing something "special" with that "event".

Note that you can still bind it with @my-event="..." syntax. It's all fairly decoupled as internally props and events share the same onMyEvent key in state.

[lucasgladding]

FWIW, I don't mind the defining it as a prop in addition to defining the event. Given that you can still consume the component with the v-on binding, emit the event internally through $emit, the only additional work is including the optional prop in that definition. That said, if this is the recommended approach, it would be nice to have some clear documentation on that (and I don't mind submitting that documentation update if the current answer is clear). I spent quite a bit of time investigating the best approach under script setup.

[adamreisnz]

I just don't see why we need a different syntax for what is essentially the same thing – an event. Consistency is key if you are training developers, and we will struggle to explain to them why they can use @click syntax for one event, but have to use v-on or onClick for another. This in itself is a code smell and red flag to me. It shouldn't require additional documentation. It requires simplification and consistency in my opinion.

[Fuzzyma]

@adamreisnz i also don't like to have 2 different syntaxes. I make heavy use of declaring events as props because I want to be able to await handlers that return a promise. However this breaks if you bind the event with @ instead of passing down the handler as prop. That's because of the way event handlers are wrapped (as explains above).
However, I think it should be made clear everywhere that @event is nothing else than a cached and wrapped prop-function.
It would help people to understand how vue works

[gund]

Vue support for events (through $emit) is really as "pure pub-sub" as it gets

I think this has some truth to it but there is nothing wrong to allow event producers to know if the event was handled by someone else (once or multiple places does not really matter).
This is exact model that DOM events follow with the preventDefault() behavior and I think most people in this discussion actually seeking a nice/non hacky solution to this, myself including.

So it would really help if a call to emit('event') could simply return a boolean flag that indicates that the event has been handled by some external handler or not.

[the94air]

The workaround mentioned will work if you're in control of both parent/child components. If you're making a wrapper component around an npm library this could become an issue. It's pretty much not possible if you're using an external library as a child component due to its typescript typing (for example when you need to pass a v-model value and event). It has to be passed as an event and that will prevent it from being conditionally emitted (unlike the props method) when it's being called from the outside of the wrapper component. Now I am not sure how to workaround this. They either have to be called as props or emits but not both. Is it the package maintainer's responsibility to decide if they are going to be added as emits or props inside of their components? or as both props and events? (which is probably not even possible rn in the current Vue)

[invokermain]

I've run into this limitation as well when trying to simply wrap a 3rd party component whilst maintaining typings.

As far as I can tell, currently you have to choose between:

1. Not declaring any emits and events working out of the box with inheritance/$attrs.
2. Redeclaring all the emits from the 3rd party component, and then explicitly hooking each one up and passing it along (extremely verbose and against DRY),

But 1. is not really favourable as I imagine it will obfuscate the events from IDEs etc. I imagine the workaround you are suggesting @jods4 will have similar issues with IDEs & autocompletion? As events as props will probably not be considered.

Being able to access emits would allow you to easily wrap a component with typings by doing:

<script setup lang="ts">
defineProps<propInterface>()
defineEmits<emitInterface>()
</script>

<template>
    <some-component v-bind="{ ...$attrs, ...$props, ...$listeners }" />
</template>

I imagine this type of wrapping is a fairly common use case enough that this should really be supported? e.g. want to just apply some styling to a 3rd party component.

I am no Vue expert anymore, but my 2 cents:

Prop is defined in your components custom props? It's in $props, else it's in $attrs.
Event listener is defined in your components custom event? It's in $listeners, else it's in $attrs.

Seems neat and tidy and discoverable to me? And if listeners are passed as props under the hood then the similarity in behaviour between $props and $listeners slightly reflects that.

It's very strange to me that as soon as you define an event in emits, any listeners are completely hidden from you? I've dug through every item in console.log(this) expecting it to exist somewhere, but cannot find the listener anywhere. But if I don't define emits, it's right there in $attrs easily accessible.

[twickstrom]

This is my argument as well. If it is accessible BEFORE you add it to emits, why is it REMOVED when you try to use best practices from the VUE docs?

It seems like an antipattern and inconsistent with the expected behaviour.

[jods4]

But 1. is not really favourable as I imagine it will obfuscate the events from IDEs etc. I imagine the workaround you are suggesting @jods4 will have similar issues with IDEs & autocompletion? As events as props will probably not be considered.

Not sure which workaround you're referring to as we discussed several, but yes I believe your analysis is correct.

• If you declare stuff, either as an emit or as a onXXX prop, you'll have to pass it down explicitly.
• If you don't declare it, it works but tooling is a drawback.

The tooling issue isn't specific to events, though. Any prop that is inherited in your template won't be visible to tooling. A general solution would be nice.

That might be something worth improving, at a glance I see two ways:

1. Tooling performs more work and if your component has inheritAttrs, it merges all (non-shadowed) props of its first child into the component own props. More complex, but would work magically for everyone.

2. We add a way to explicitly declare special attrs that are meant to be inherited, so that tooling can surface them to consumers.
   Much simpler for Volar, but this adds new API surface and requires extra work from every user.

[invokermain]

I actually believe that the removal of $listeners might have been premature? RFC 31 does not seem to sufficiently motivate it, it barely discusses it, just says it will be removed? The use cases in the discussion above surely show that there is a benefit and need to having access to those listeners even when using emits to say that they are custom events of your component.

[Anoesj]

$listeners made so much more sense...

[arthabus]

Agreed. It seems this decision wasn't very well thought through regarding the real-life implications for the existing projects.

[devopg]

today i lost 3h for 3 line of code thx...

what is the current solution?

import { useAttrs } from 'vue'
const attrs = useAttrs();

if(!attrs['mySuperEvent']) {
    doDefaultFunction();
}

[renatodeleao]

Joining the thread. In process of migrating a huge codebase to vue3 and this is the task I am spending the most time on by very very far. $listeners was super useful for composition:

Before

<!--before -->
<template>
  <!-- emits "app-event" -->
  <app-base-component>
    <!-- also emits "app-event" -->
    <app-other-component v-on="$listeners" />
  </app-base-component>
</template>

After

<!--after -->
<template>
  <app-base-component v-bind="fallthroughtAttrs">
    <!-- 
      cannot do v-bind="$attrs" because that includes actual attributes like 
      class, style and other html attributes i don't want to foward 
     -->
    <app-other-component v-bind="forwardListeners" />
  </app-base-component>
</template>

<script>
  import { omitAttrsListeners, pickAttrsListners } form '@/utils'
  
  export default {
    // AppBaseComponent have the same "app-event" listener and i don't want it bound
    // to root component only forward to AppOtherComponent, so i disable the default behaviour. Not that by "app-event" i mean
    // " a common generic name like "click" "update" etc.
    inheritAttrs: false,
    // Alternatively I could add the emits option to remove it from $attrs and prevent the
    // above scenario, but if I do i'll break the "isInteractive" computed prop and the event will
    // also not be forwarded to AppOtherComponent which was the original goal
    // emits: ['app-event']
    computed: {
      // So i still want to fallthrough actual attributes
      fallthroughAttrs() {
        // omits any onX attr
        return omitAttrsListeners(this.$attrs)
      },
      forwardListeners() {
        // picks any onX attr
        // Oh do you want to use it on v-on directive? you still have to remove "on" prefix
        // and normalize the event name to kebab-case. Make sure your util has that option
        return pickAttrsListeners(this.$attrs)
      },
      isInteractive() {
        // before this.$listeners['app-event']
        // Only works if i don't add emits option.
        return !!this.$attrs.onAppEvent
      }

    }
  }
</script>

Of course, we might argue that instead of auto-fallthrough things we should document explicitly what the component receives and emits. I can agree with that to some extent, even if it's more laborious (imagine a component with 10 events). Still does not solve the isInteractive issue.

The workaround checking if a listener was bound

Declaring an 'onPropX' and then using a prop as @prop-x as if it was an event? Say what?!
I've been on vue for the past 6 years — if recall correctly and I've been away from vue3 for far too long, unfortunately — but that didn't even cross my mind because, to me, they've always been clearly separated concepts. I mean I know that they were merged into the same "object", but "merging" its definitions and blurring the line between an event and prop is a bit too far for me IMO.

[thedamon]

class/style/otherattrs/listeners are distinct things and it's convenient to have them in one place easily (new attrs), but it is really unfortunate to have no good way to parse them out without annoying utility functions. What you describe here seems like a pretty reasonable thing to want to do (esp since class and style often make more sense on a wrapper when other attrs are passed in further..)

I'd encourage you to include the code for your utility functions as well, because many ppl will now need to use these utility functions to replicate things that were very simple in Vue 2.. it will further demonstrate the difference in amount of code as well as useful for others to copy/paste ;)

[adamreisnz]

Would be good to get some feedback from the Vue team on this. There seem to be some valid concerns in the community about the lines between these concepts having been blurred too far. Are there any plans to revisit this decision and potentially reintroduce some syntactic sugar to differentiate props and events better? (Even if they are the same object under the hood?)

[arthabus]

Agreed on that. During migration of a fairly big project I ended up writing my own computed properties like attrsNoListeners and attrsListenersOnly in the base component and use those instead of the this.$attrs to keep the migration process under control.

Would be great to have a centralised discussion on that with the now-gathered real-life use cases from the community.

[thedamon]

I find the combined $attrs generally frustrating coming from Vue2, for the reason that's the inspiration for this thread (which I haven't run into yet but definitely does not feel intuitive — declaring an emit as a prop in order to know whether it exists doesn't feel right.) and for the inability to do reasonable things like separating $listeners out of $attrs without weird utility functions.

If we could easily retrieve categorized aspects of listeners somehow, this would really help to remediate all these problems:

const {class, style, listeners, emitListeners, htmlAttrs } = useSortedAttrs()

[arthabus]

Yeah, and here is one of those weird utility functions I ended up using exactly to separate $listeners out of $attrs. Idk, maybe it will help someone:

attrsListenersOnly() {
    let attrs = {}
    for (let key in this.$attrs) {
        if (key.match(/^on[A-Z]/)) {
            attrs[key] = this.$attrs[key]
        }
    }
    return attrs
},

It uses the fact that in Vue3 anything that starts with "on" followed by a capital letter is considered a listener

[AlansCodeLog]

Just ran into this. I scoured the docs trying to find what I was doing wrong, but they all seem to imply this should work (like for example here https://vuejs.org/guide/components/events.html#declaring-emitted-events), it doesn't say all listeners, just known listeners which makes this seem like a bug, or am I misunderstanding this?:

Although optional, it is recommended to define all emitted events in order to better document how a component should work. It also allows Vue to exclude known listeners from fallthrough attributes, avoiding edge cases caused by DOM events manually dispatched by 3rd party code.

If this is intended behavior, at the very least there should be a warning for users of a component when they try to pass listeners that are deleted.

Another thing I noticed is that the types of the components are too strict regardless, and generate type errors on extra properties. And because the autogeneration of typescript emits/props can't use imports, it's not easy to tell defineProps that there can be extra listeners/properties without defining them all, otherwise this wouldn't be such a problem.

I'm working on a component lib I've tried all sorts of thing to get around this but the two things that work short of re-declaring all events, all have downsides:

• Passing all events in a single prop.
  • Makes component weird to use, but at least types are preserved. User must pass events like on* and they cannot use event modifiers like @keydown.enter.

<script lang="ts">
	import { type Events,  ... } from "vue" 
	type EventHandlers<E> = { // taken from vue type defs
		[K in keyof E]?: E[K] extends (...args: any) => any
	    ? E[K]
	    : (payload: E[K]) => void
	}
	const props = withDefaults(defineProps<{
		listeners?: Partial<EventHandlers<Events>  & Record<string, any>>
	}>(), {
		listeners: () => ({}),
	})
})
</script>

//user

<lib-component :listeners="{
	onKeydown: () => {}
}"/>

• Removing emits, typing the emits in an extra regular script using export default, and using getCurrentInstance().emits in the script setup:
  • This is a mess, requires manual exclusion of emits from $attrs, and I get no typing info on emits within the component, but the user can keep using the component how I'd expect.

<script lang="ts">
export default {
	inheritAttrs: false,
	emits: {} as any as {
		"update:modelValue": (val: string) => void
	},
}
</script>
<script setup  lang="ts">
const $attrs = omit(useAttrs(), ["onUpdate:modelValue"])
const emit = getCurrentInstance()!.emit
</script>

Edit: It was wrong in the first example to use Events, vue internally converts them into the proper function types using EventHandlers<Events> which HTMLAttributes inherits.

Anyways I heard about the new expanded type support for defineProps and thought finally, I can just import HTMLAttributes or re-recreate EventHandlers<Events> but vue chokes on the K in keyof in EventHandlers with Failed to resolve index type into finite keys. Am going to see if with some minor editing I can get the types working.

[samueleiche]

Our team is also migrating from Vue 2.x and ran into this issue. Adding the listener via props feels unconventional in our codebase so I'm forced to add an additional prop to validate whether the listener exists or not.

<MyComponent clickable @click="() => {}" />

<script>
export default defineComponent({
	emits: ['click'],
	props: {
		clickable: Boolean,
	},
	...
})
</script>

Edit: after some reading and testing I've found a better solution than the one above. This works even if you don't have emits defined. I'm not a fan of magic code, but seeing how listeners are handled in Vue 3, this feels okayish.

<MyComponent @click="() => {}" />

<script>
export default defineComponent({
	emits: ['click'],
	props: {
		onClick: Function // use to determine if component has `@click` listener
	},
	// So basically @click is turned into an onClick prop
	computed: {
		hasClickListener() {
			return !!this.onClick
		}
	}
	...
})
</script>

[adamreisnz]

Is there any discussion at the Vue team to revert this change or otherwise address this issue? It keeps coming up and clearly affecting a lot of teams, probably more so those working on larger, more complicated apps.

…

On Sat, Apr 29, 2023, 00:55 Samuel Eiche ***@***.***> wrote: Our team is also migrating from Vue 2.x and ran into this issue. Adding the listener via props feels unconventional in our codebase so I'm forced to add an additional prop to validate whether the listener exists or not. <MyComponent clickable @click="() => {}" /> <script>export default defineComponent({ emits: ['click'], props: { clickable: Boolean, }, ...})</script> — Reply to this email directly, view it on GitHub <#397 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADXYQTWSCMA22BA2255VIDXDO42VANCNFSM5FLI55AA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[the94air]

Kinda feels like any fix would land on the next major release 😿its too late

[hymair]

Our usecase: We have a pretty flexible BaseTable component (even more so now with the new generic props). We are checking for @click handlers attached from the parent and depending on that we apply some additional classes (hover, cursor style etc.).

This is no longer possible in Vue3 without adding extra (hacky) code.

[dalezak]

I ran into this same problem in Nuxt + Vue + Ionic app, suggestion from Vue Land slack channel led me to the following solution.

Parent with search

<top-bar :search="search" @search="searchItems()"></top-bar>

Parent without search

<top-bar></top-bar>

Child

<ion-searchbar type="search" :value="search" @ionInput="doSearch" v-if="hasSearch"></ion-searchbar>

const props = defineProps({
  search: {
    type: String,
    default: ""
  },
  onSearch: {
    type: Function
  }
});
const hasSearch = props['onSearch'] !== undefined;
function doSearch() {
  if (props.onSearch) {
    props.onSearch();
  }
}

This allows me to show or hide the ion-search in the child component based on whether the parent provide @search.

[arthabus]

Maybe this will help someone.

In my project I ended up creating corresponding computed properties in my base component like this:

<script>
...
computed: {
  attrsNoListeners() {
    let attrs = {...this.$attrs, ...this.$props}
    for (let key in attrs) {
      if (key.match(/^on[A-Z]/)) {
        console.log("attrNoListeners: removing key = ", key)
        delete attrs[key]
      }
    }
    return attrs
  },
  attrsListenersOnly() {
    let attrs = {}
    let attrsProps = {...this.$attrs, ...this.$props}
    for (let key in attrsProps) {
      if (key.match(/^on[A-Z]/)) {
        console.log("attrsListenersOnly: adding key = ", key)
        attrs[key] = this.$attrs[key]
      }
    }
    return attrs
  },

// additional helpers to manually pass styles when using "inheritAttrs: false"
  attrsStylesClass() {
    let {style, class: clazz} = this.$attrs
      return {style, class: clazz}
    },
  attrsNoStylesClass() {
    let {style, class: clazz, ...rest} = this.$attrs
    return {...rest}
  },
},
</script>

Whenever I need granular controls over attrs/props when it comes to listeners, I extend this class and use the corresponding computed prop.

[thedamon]

I suggested a vueUse composable to give easy access to this stuff when we need it that I would welcome feedback on: vueuse/vueuse#3550

I think that would be a good place for a community workaround to save people implementing and reimplementing themselves

[Joey-Gr]

Facing the same issue here, using Nuxt3 in <script setup> (but this detail should be unrelated, it's still using Vuejs3). Our solution for now was passing an "options" object in the props of the component, which contains keys like "'hoverable': true, 'shadow': true, 'grow': true, 'clickable': true". After that we made a function which returns the appropriate classes we want directly into the template, although a more proper way would be great. Hope this helps anyone in the meantime!:

  const props = defineProps({
    id: { type: String, default: "" },
    data: { type: Object, default: null },
    options: { type: Object, default: null }
    ...
  })
  const { id, data, options } = toRefs(props)

 const incrementClasses = (options) => {
    if (options) {
      let tmp = []
      if (options.hoverable) tmp.push('list-group-item-action')
      if (options.shadow) tmp.push('shadow')
      if (options.grow) tmp.push('grow')
      if (options.clickable) tmp.push('cursor-pointer')
      return tmp.join(' ')
    }
    return ""
  }

...

<template>
   <div class="card" @click.stop="..." :class="incrementClasses(options)" >
      ....
   </div>
</template>

[ZiadJ]

It tried it with the typescript version that does destructuring and enables reactivity in one go but it turned out to be quite problematic when done in two steps like you did. It might seem fine initially but we can't set default values for booleans then, for reasons I can't explain. I'm using it with propsDestructure: true in the Vite configuration btw, and ended up using $props instead, which is available in the template wherever I need it.

[Joey-Gr]

Ah, that is very true. You would need to add a list of every possible option as a default object in the options Object, but I can see how that becomes problematic when there are a lot of options

[ZiadJ]

So they removed access to events but then what's the workaround? If there's none then what's the rationale behind?

I'm making a wrapper component and need to pass all event handlers to the child. For props, v-bind="$props" comes handy but how about for event handlers?

[arthabus]

Events are now in $attrs, so you do v-bind="$attrs", or in your case v-bind="{...$attrs, ...$props}". Unless you specify your listeners in the emits section by their names (docs link), in which case they won't appear in $attrs but rather as separate properties and you would then pass them explicitly by name.

Also consider adding inheritAttrs: false to your components or otherwise your events might end up being called twice as the listeners will be attached to the root element of your component. But if you want to preserve class inheritance, you'd need to pass classes/styles manually in this case

Not sure abut rationale, but it was quite a nightmare to migrate that part in my project. I ended up building separate computed attrs that sort of mimics the Vue2 approach which gives me flexibility to decide what to pass.

[douglasg14b]

afaik they are no longer in $attrs if you are using defineEmits()

[tlloydthwaites]

I just came across this migrating to Vue3. We have some components that have default behaviour that you can override by mapping the event.

This is simply no longer possible and a huge pain. $listeners is not hurting anyone, so why not just put it back in?

[lnvglr]

I found a pretty sweet workaround for any <Component @click="handleClick" value="someValue" />:

// Component.vue

<script lang="ts" setup>
  defineProps<{ value: string }>()
  defineEmits(['click'])
  const clickEventListener = getCurrentInstance()?.vnode.props?.onClick // handleClick
</setup>

It seems, vnode.props holds all props (including event handlers) that were passed to the component.

This is where it is implemented in Vue core

[dalezak]

I'm using Nuxt 3 and Ionic, but the following worked for me.

Component

<template>
  <ion-searchbar :value="search" @ionInput="doSearch" v-if="hasSearch"></ion-searchbar>
</template>
<script setup>
const props = defineProps({
  search: {
    type: String,
    default: ""
  },
  onSearch: {
    type: Function
  }
});
const hasSearch = props['onSearch'] !== undefined;
function doSearch(event) {
  if (props.onSearch) {
    props.onSearch(event.target.value);
  }
}

Page

<template>
<search-bar :search="state.search" @search="searchChanged"></search-bar>
</template>
<script setup>
const state = reactive({
  search: ""
});
function searchChanged(search) {
  console.log("searchChanged", search);
  state.search = search;
}
</script>

[JohnyWills1]

For others that may be trying to convert a page/component that uses the Options API to use Composition API this is a easy trap to fall into. I was trying to convert a computed variable which was trying to detect if a @close event was being passed to a custom component.

Using the old Options API it looked like this:

return typeof this.$attrs.onClose !== "undefined";

However trying to refactor this to use the useAttrs() hook described on the Vue.js Documentation did not work:

import { useAttrs } from 'vue';

const attrs = useAttrs();

❌ Only returns "undefined" ❌
const x = computed(() => {
  return typeof attrs.onClose !== "undefined";
}

Instead @dalezak's answer helped solve my problem. Simply adding a prop which matches the @event you are passing your component will be assigned that value:

interface CustomComponentProps {
  onClose?: () => void;
}

✅ This correctly returns whether the custom component is being passed a "@close" event ✅
const x = computed(() => {
 return typeof props.onClose !== "undefined";
}

This might seem obvious to some but I have not been using Vue.js for too long. I am not too familiar with migrating Options API components to use Composition API, so I thought posting this would be helpful to others like me.

[lnvglr]

Beware this only works if you did not define your emits using defineEmits(['close']), which is common practice.
If you defined your emits, you need to get the onClose like so: getCurrentInstance()?.vnode.props.onClose.

See: #397 (comment)

[maxflex]

Makes no sense. Spent a couple of hours with no real solution found.

Now the code is not concise:

<MyComponent selectable @select="onSelect" />

And in MyComponent.vue:

const { selectable } = defineProps<{
  selectable?: boolean
}>()

[samueleiche]

If you define a prop onSelect, it will get assigned when you have a @select listener.

[stevebauman]

Hallelujah! I discovered a solution for this if your event has a colon 🎉

Register a prop with the syntax 'on{Event}:{name}':

Here's an example:

<Datatable @click:export="() => {}" />

<template>
    <button @click="startExport">Export</button>

    <table>
        <!-- ... -->
    </table>
</template>

<script>
// datatable.vue

export default {
    props: {
        'onClick:export': {
            type: Function,
            default: null,
        },
    },

    emits: ['click:export'],

    methods: {
        startExport() {
            this.$emit('click:export');

            if (this['onClick:export']) {
                // Listener is set.
            } else {
                // No listener set.
            }
        }
    },
}
</script>

[turbobuilt]

I will explain theoretically why this should be added.

Every framework, theoretically, should only add functionality, never remove it. Otherwise developers have to choose which is better.

By removing attrs support, this violates a fundamental law of framework design - never remove functionality!

[arthabus]

This is a matter of debate. Personally, I think removing events from attributes was a mistake. However, deprecations and breaking changes are common, and there’s no absolute rule like that in framework design.