Cool, thank you! Should theinline-function style really already be accepted with one argument (whereinline would also work with$event), or only with two or more?

This would prevent the interdiction to use$event in favor of explicit naming:

<template><!-- Using an inline function with a good argument name is better-->  <MyComp@increase="(count) => myHandler(count)" />`<!-- It's why we don't allow $event, as it is meaningless (and is absolutely not an Event here)-->  <MyComp@increase="myHandler($event)" />`</template>

Edit: Or maybe it could be configurable as an option?

I think if you want to force explicit parameter naming, then you should only allowinline-function. It's 5 extra characters for functions without parameters (() =>), but it's a simple and effective rule.

If you prefer shortness over explicitness however, then["inline", "inline-function"] is fine, but IMO it should only fall back toinline-function wheninline does not work at all, i.e. only for functions with more than one parameter.

I see your point, but it's really common to only need an inline handler.

I don't think we should force users to use@event="() => handler()" where@event="handler()" is enough.

The primary goal of this PR is to forbid the usage of method handler, as it's error prone, and allow the two others.

I updated my proposal to add anallowInlineFuncSingleArg?: boolean option that can only be used in conjunction with['method', 'inline-function'] or['inline', 'inline-function'].

• WhenallowInlineFuncSingleArg istrue:

  ❌() => handleFilter()
  =>handleFilter() if['inline', 'inline-function']
  =>handleFilter if['method', 'inline-function']

  ✅(filter) => handleFilter(filter)

  ✅(filter, negate) => handleFilter(filter, negate)

• WhenallowInlineFuncSingleArg isfalse (by default)

  ❌() => handleFilter()
  =>handleFilter() if['inline', 'inline-function']
  =>handleFilter if['method', 'inline-function']

  ❌(filter) => handleFilter(filter) =>handleFilter($event)
  =>handleFilter($event) if['inline', 'inline-function']
  =>handleFilter if['method', 'inline-function']

  ✅(filter, negate) => handleFilter(filter, negate)

Hmm, I don't like the extra option. The logic is quite convoluted already anyway, and the extra option makes it even harder to understand.

But I think we can change the rule like this:

1. For cases like@click="(arg1, arg2) => handler(arg1, arg2)", always allow theinline-function style, because there is no other way to represent those. Multiple event payloads should rather be reported at the emitting side, seeRule suggestion:vue/prefer-single-payload-in-event #2005
2. Add a new option["inline", "inline-function"] that allowsinline but disallows using$event, and allows usinginline-function in that case.

What do you think?

Thank you for your reply.

After some thought, I wonder if this rule isn't trying to handle too many things at once.

I agree on your first point (although I thinkvue/event-prefer-single-payload would be a better name. At first I read "Prefer Single-Event Payload" ^^)

Perhaps it would be easier to disallow these different behaviors with new, independent rules?

For example:

1. @click="count++" ➡️ Disallow withvue/event-no-inline-expr
2. @click="increase" ➡️ Disallow withvue/event-no-method-handler
3. @click="increase()" ➡️ Disallow withvue/event-no-inline-handler
4. @click="() => increase()" ➡️ Disallow withvue/event-no-arg-less-inline-function
5. @click="increase($event)" ➡️ Disallow withvue/no-dollar-event
6. @click="(count) => increase(count)" ➡️ No reason to disallow?
7. @click="(count, multiply) => increase(count, multiply)" ➡️ No reason to disallow?

This is just a quick overview, and I may be overlooking certain situations.

Thanks for working on new option and for the suggestions.

However, for now I don't think it's a good idea to split up what thev-on-handler-style rule is doing, because I think it would be hard to design the options in such a way that those rules don't conflict.

@ByScripts are you interested in changing the rule like I described in mycomment above?

I just stumbled on this one when going through a larger codebase which has been using the method-style when defining v-on event handlers. Shouldn't the vue/v-on-handler-style rule by default forbid using the method style as in Vue 3 the onClick event is not cached when the function is typed without parentheses?
Here's an example:

Not cached:

Cached: