How about same-name shorthands for events as well, aka. @my-event

[toniengelhardt]

The recent introduction of same-name shorthands for component props is amazing, aka we can now do

<Item :item :readonly />

instead of

<Item :item="item" :readonly="readonly" />

which improves readability and code style.

How about the same for events, aka

<script setup lang="ts">
function myEvent($event) {
	doSomething($event)
	// do something else...
}
</script>

<template>
	<Block :block :readonly @some-event />
</template>

instead of

<template>
	<Block 
		:block
		:readonly
		@my-event="myEvent"
	/>
</template>

IMO this would improve consistency and simplify passing events up the tree when necessary, e.g. if template refs are involved.

[skirtles-code]

To some extent it is already possible to use the v-bind same-name shorthand with events. e.g.:

<script setup>
function onClick() {
  // ...
}
</script>
<template>
  <button :onClick>Save</button>
</template>

Or to use an object with v-bind:

<script setup>
function onClick() {
  // ...
}
</script>
<template>
  <button v-bind="{ onClick }">Save</button>
</template>

That second example can also be adapted to work with v-on:

<script setup>
function click() {
  // ...
}
</script>
<template>
  <button v-on="{ click }">Save</button>
</template>

Here are all three of those examples combined into a Playground:

• Playground

---

Part of the reasoning behind introducing the same-name shorthand was that it was common to have things like :user="user" in the template. In many cases it makes sense for the local data and child prop to have the same name.

For events that's significantly less common. An event is typically named after something that has already happened in the child, which often doesn't work so well as a function name in the parent. It's much more common to have something like @click="onClick" or @click="clickHandler" or @click="save" or @click="onClickSave".

But perhaps @click could be used as a shorthand for @click="onClick", following a common naming scheme used for listeners.

Unfortunately, there's a bigger problem...

---

Consider this code:

<form @submit.prevent>

This is a fairly common usage, used to prevent a form from submitting. There is no handler here, it just needs to prevent the default action. If we introduced a shorthand for events then this would now be short for @submit.prevent="submit" or @submit.prevent="onSubmit". That would likely be a breaking change for a lot of codebases.

[toniengelhardt]

Thanks for the detailed explanation, makes sense 🙏🏽