Vue: v-on to bind dom event in a custom component

[Jinjiang]

In Vue 2.0 if we need to offer some common dom event features, we have to write each of them in custom components itself.

for example

main.vue:

<template>
  <btn @click="go">Click Me!</btn>
</template>
<script>
  module.exports = {
    components: {
      btn: require('btn.vue')
    }
    methods: {
      go: function (e) {
        // todo: go to a certain url
      }
    }
  }
</script>

btn.vue:

<template>
  <button @click="click" @mouseenter="mouseenter" @mouseleave="mouseleave" ...><slot></slot></button>
</template>
<script>
  module.exports = {
    methods: {
      click: function (e) {this.$emit('click', e)},
      ...
    }
  }
</script>

But I think that's not necessary.

[yyx990803]

I think it's better to be consistent than convenient. Listening to both
component and native dom events makes it unpredictable - what if there is a
new dom event introduced in the future? What if a library is dispatching
custom dom events? What if you happen to use a custom event name that is
also a native dom event? It's just too confusing to listen to both at the
same time and can lead to very hard to debug bugs.
On Mon, May 23, 2016 at 11:44 PM 勾三股四 [email protected] wrote:

In Vue 2.0 if we need to offer some common dom event features, we have to
write each of them in custom components itself.

for example

main.vue:

btn.vue:

But I think that's not necessary.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/vuejs/vue/issues/2942

[Jinjiang]

Well in another way, I think v-on in most html elements mean native dom event so that's also confused me sometimes (such as why <div @click> works but <foo @click> not). How about preserve v-on in custom component just listen to native dom events and we can have another syntax to listen custom event declaratively instead?

[yyx990803]

Hmm, maybe add a modifier:

<foo @click.native="hello">

[Jinjiang]

I prefer <foo @internal.custom="xxx" @click="yyy">, just personal favor 😜. The native and custom event case is 60%-40% for me.

[yyx990803]

Custom events is the recommended way for custom components to produce side effect in the parent, especially now that two-way props are deprecated. It will be much more commonly used in 2.0.

[kushalmahajan]

@change fires on blur out. @input captures every keystroke. Confusing!

And referring to the discussion above.

It's just too confusing to listen to both at the
same time and can lead to very hard to debug bugs.

Are you talking from building core framework specific issues Evan? If not, framework or library can always warn developer on use of same name of custom event as native.

I think delegation for custom components for native events should be treated the same way. Also, people coming from different ecosystems might not expect this(modifier). I'm lucky to waste not more than 15-20 mins.

I ran through this and posted this issue here using Jsx and styled components. Your answer helped but it's a deviation.

Just a pointer from an experienced React user!

[patomation]

I'll chime in 2 years later.
I was a bit confused when my custom components did nothing with @click.
And now I'm finding out that v-on:click.native is deprecated?
What replaces this? click.enter does not work.
What's the point of using components if you can't use click events in a logical way?