Skip to content
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

Kebab case event listeners broken #2525

Closed
cathrinevaage opened this issue Oct 30, 2020 · 1 comment
Closed

Kebab case event listeners broken #2525

cathrinevaage opened this issue Oct 30, 2020 · 1 comment

Comments

@cathrinevaage
Copy link
Contributor

Version

3.0.2

Reproduction link

https://codesandbox.io/s/eloquent-cdn-yipvt?file=/src/App.vue

Steps to reproduce

Attach an event listener on a component using kebab-casing.

<SomeComponent @some-event="someListener" />

In the component, emit an event using with any camel, Pascal, or kebab casing ('some-event', SomeEvent, someEvent).

What is expected?

The event listener should be called.

What is actually happening?

The event listener is not called.


This is a duplicate of #2429, but closed issues seem to get little attention, so I'm creating a new one with working reproductions and some insight.

As of #2278, listeners added with camel casing broke.
In that pr, all events, both listener names, and emitted event names, were converted to camelCase.

@some-event="someListener" is compiled to the vnode prop onSomeEvent: _ctx.someListener, as can be observed in the template explorer.

However, this can not be observed in the compiled template in the app. The render function for App.vue is printed in the console in the reproduction. Here you can see that it's compiled the same way as it was in v3.0.0; "onSome-event": _ctx.someListener.
When the emitted event is converted to camelCase, the handler can't be found.

I believe this is the cause of the issue.

@cathrinevaage
Copy link
Contributor Author

This is not reproducible when creating a fresh new project with e.g vite.
Even though, in codesandbox, the compiler is clamped to ^3.0.1, the wrong behaviour persists. I suspect this is an issue at their end instead.
Closing.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant