Coding is subjective, it is always possible to do things in several different ways. Usually frameworks are opinionated, and there are some conventions, and some forms are more commonly accepted than others. Here I present you the way I like to structure my events in Vue and the rationale behind it.

I am a big fan of static typing and I firmly believe it can help in having a more enjoyable development experience, I won't argue if the code is more robust or not because the reason I really like it is because it help me avoid surprises and shape a code abstraction easily, both things related to having a pleasant coding experience since I often spend quite a good time doing it. The idea here can be better implemented with typescript but I find it equally useful with plain javascript.

Instead of using strings for events and then the @ shortcut notation for listeners. I recommend creating an object or an enum and having all the events there as a dictionary, then creating another object having the dictionary values as keys and the listeners as value. The downside of this is that it is a bit more verbose than using @event, but as the number of events and listener grows this is less evident.

In Vue's docs it appears under Object Syntax for v-on in the API section. In code that would be:

<template>
  <some-vue-component
    v-on="someVueComponentListeners"
  />
</template>
<script>
  // This should be part of SomeVueComponent SFC
  const SomeVueComponentEvents = {
    CLICK: 'click',
    CUSTOM_EVENT: 'custom-event'
  };
  // We assume somewhere inside of it there is a:
  // this.$emit(SomeVueComponentEvents.CLICK);
  // this.$emit(SomeVueComponentEvents.CUSTOM_EVENT);
  const someVueComponentListeners = {
    [SomeVueComponentEvents.CLICK]: () => { /* do something */},
    [SomeVueComponentEvents.CUSTOM_EVENT]: () => { /* do something */},
  };
</script>

Consistent search

The first advantage of this way of handling events is that it will be very easy to search, both the emitter and the listener have the same Object.Key notation.

Move logic to the script section

All your logic will be available in the script section of the SFC, probably you will still need to check the template from time to time but now you don't need to go to the template to see which handler correspond to which event.

More concise templates

As a consequence of the previous point, the component tag is now uncluttered, which is particularly visible for container components with many handlers. Now you can't know anymore from the template which handlers are implemented (depending on the IDE you are using you may be able to see it, with VS Code IntelliSense provide this information).

Thanks for reading, I'll be happy to read your thoughts and comments. If you found this post interesting please consider following me here or in Twitter.