Events are not hypenated

[paulpflug]

Vue.js version

1.0.21

Reproduction Link

https://jsfiddle.net/paulpflug/5sH6A/312/

Steps to reproduce

// in component
this.$emit("testTest") // camelCase

// outside
<comp @test-test="test"></comp>

What is Expected?

Event should be called

What is actually happening?

Event isn't called

This is a bit delicate.
When working with attributes it is totally clear to expect the same behavior as props.
current behavior:

case	$emit	$on in code	v-on in attributes
1	camelCase	camelCase	not possible
2	lowercase	lowercase	lowercase /camelCase
3	hypenated	hypenated	hypenated

I think this makes more sense:

case	$emit	$on in code	v-on in attributes
1	camelCase	camelCase	hypenated
2	lowercase	lowercase	lowercase /camelCase
3	warn to use camelCase	warn to use camelCase	hypenated

[yyx990803]

The current suggestion is simply avoid using camelCase event names, because there's no particular reason to do it.

[bartlomieju]

In my app I followed hook:created syntax making it something like this origincomponent:eventname. Vanilla JS events are mostly all lowercase so I guess it makes sense to stick to that solution in Vue

[paulpflug]

I have three arguments:

• camelCase allows to omit the quotes in the events property:

events:
  someEvent: -> # allowed without qoutes

• different behavior than props is confusing, as besides of that, the usage pattern is very similar

<comp :some-prop="someThing"></comp>
# vs.
<comp @some-event="someThing"></comp>

props:
  someProp: {}
# vs.
events:
  someEvent: -> # only that this currently won't work

• currently camelCase events are incompatible with v-on

[rpkilby]

fwiw, I'm kind of 50/50 on this.

thoughts:

• The quoted & dasherized handler name is kind of meh. It would definitely read nicer as camelCase.

  Vue.extend({
    events: {
      'some-event'(...args) { ... },  // -1
      someEvent(...args) { ... },  // +1
  });

• Usage consistency w/ props is also nice.

• That said, camelCase handling for props is necessary since you need to call them in code. That is not the case for the event handlers.

• I would expect event dispatching to use the dasherized form, although dasherized and camelCase could probably both be accepted without conflict.

• In general, I would expect prop and event names to normalize to the dasherized form - camelCase is used for convenience/compatibility with javascript.

[azamat-sharapov]

The quoted & dasherized handler name is kind of meh

Readability. It helps to distinguish events from methods. And usually, events are more human readable: 'comment-deleted', 'user-logged-in', 'event-happened'.

[rpkilby]

@azamat-sharapov - that's a good point. 'some-event'() {} still looks a little awkward, but it definitely does help distinguish event handlers from regular methods.

[paulpflug]

I oppose, the usage pattern for events and methods is totally different. I can think of no way to confuse the both.
Wherever I can, I use the same names intentionally:

events: {
  doStuff: doStuff
}
// or
this.$on('doStuff',this.doStuff)
// both look super clean to me..

[nirazul]

I usually try to emphasize the difference between events and methods. An event doesn't necessarily carry any information about what is needed to react to it. For example, a cancel button of a form within an overlay dispatches an event that I'd call overlay-form:cancel-requested.
Maybe I'd like to close the overlay, as the user doesn't intend to fill out this form right now, but mabye the form is mandatory and he needs to fill it.
I'm aware that there are hundreds of ways to do this, but for me it works by separating information about actions into events (the next step was requested, a cancel was requested) and the resulting orders into methods (react to the request by doing xy). It shifts the intent to react from the informational event (sth. happened) to the method that handles it (what do I do now).

[paulpflug]

So to conclude:

• We need to keep hyphenated events working as they do now, no warn to use camelCase as I suggested
• camelCase remains to be unsupported by v-on directive

another suggestion:
let v-on bind to someEvent and some-event when a hypenated form is detected.
Difficulty would be, when someEvent and some-event actually mean different things, how likely is that? Is taking that risk better or worse of not supporting camelCase at all?