New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v-on to bind dom event in a custom component #2942

Closed
Jinjiang opened this Issue May 24, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@Jinjiang
Member

Jinjiang commented May 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@yyx990803

yyx990803 May 24, 2016

Member

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 勾三股四 notifications@github.com 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:

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

btn.vue:

<script> module.exports = { methods: { click: function (e) {this.$emit('click', e)}, ... } }</script>

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
#2942

Member

yyx990803 commented May 24, 2016

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 勾三股四 notifications@github.com 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:

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

btn.vue:

<script> module.exports = { methods: { click: function (e) {this.$emit('click', e)}, ... } }</script>

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
#2942

@yyx990803 yyx990803 closed this May 24, 2016

@Jinjiang

This comment has been minimized.

Show comment
Hide comment
@Jinjiang

Jinjiang May 24, 2016

Member

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?

Member

Jinjiang commented May 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@yyx990803

yyx990803 May 24, 2016

Member

Hmm, maybe add a modifier:

<foo @click.native="hello">
Member

yyx990803 commented May 24, 2016

Hmm, maybe add a modifier:

<foo @click.native="hello">
@Jinjiang

This comment has been minimized.

Show comment
Hide comment
@Jinjiang

Jinjiang May 25, 2016

Member

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

Member

Jinjiang commented May 25, 2016

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

@yyx990803

This comment has been minimized.

Show comment
Hide comment
@yyx990803

yyx990803 May 25, 2016

Member

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.

Member

yyx990803 commented May 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kushalmahajan

kushalmahajan Oct 5, 2018

@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!

kushalmahajan commented Oct 5, 2018

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment