[jsx-handler-names] Option to enforce only for class methods

[IanVS]

This is a useful rule, but it can sometimes get annoying when I want to use a prop or a method from a library directly as a handler. I think the real benefit to the rule is to force me to name my component's methods appropriately, but as it currently works, I sometimes need to do silly things like const handleSelect = props.entities.toggleItem;.

I would really like an option which prevents:

<MyComponent onChange={this.doSomething} />

// or in a stateless component:

<MyComponent onChange={doSomething} />

but still allows:

<MyComponent onChange={library.doSomething} />

<MyComponent onChange={this.props.doSomething} />

// or in a stateless component:

<MyComponent onChange={props.doSomething} />

Does that make any sense?

[palnes]

I second this one, plenty boilerplate if you import a library. OTOH, it might be better to abstract libraries away in this manner? But would be nice to have a choice.

[lencioni]

I'd be happy to review a PR that adds this as an option.

[robatwilliams]

Some of this, I think, could be covered reasonably straightforwardly by checking the prefix of the handler name. Only apply the rule if it begins with (this. but not this.props) or something other than props.

But I don't think that's a good approach. It's unchecked by default, can be bypassed quite easily, and would remove all enforcement when using destructured props. Anything more advanced would need to know about more than just the JSXAttribute. Any pointers on other rules that could inspire an approach?

(First time here looking at rule implementation)

[deerawan]

I think this option could solve my problem as well. I have a situation where I want to avoid the rule to check method from prop

This below is valid because onStop comes from property

// GOOD
interface CarProps {
  brand: string;
  onStop: () => void;
}

const Car = ({ brand, onStop }: CarProps) => {
  return (
    <h1>{brand}</h1>
    <button onClick={onStop} />Stop</button>
  )
}

However, the rule will fail if I have this component method

// BAD
interface CarProps {
  brand: string;
}

const Car = ({ brand }: CarProps) => {
  // It should be `handleStop`
  const onStop = () => { console.log('stop'); }

  return (
    <h1>{brand}</h1>
    <button onClick={onStop} />Stop</button>
  )
}

[ljharb]

Why not ({ brand, onStop: handleClick }): CarProps) => {?

[stevensacks]

@ljharb Sometimes, you need to prop-drill (just a little), and renaming onXXX functions in prop destructuring just to allow this eslint rule to work is cumbersome.

If this rule was able to detect that the function was declared in the body of the component vs coming from props, that would be amazing. Without that, we have to leave the rule turned off or turn it off in the file.