No need to require handler names to be scoped to an object

[aub]

In the jsx-handler-names rule, the code requires that the handler being checked is scoped to an object. This means that it will check onChange={this.wackyHandler} but because it requires the scoping it won't attempt to check handlers like onChange={wackyHandler}. In React.FC components we use this type of handlers all the time, since you can pass a locally-defined function as the handler. This change just removes a test that was causing it to return without the object scoping and then adds tests for a few conditions that it now covers.

[ljharb]

The rule is not intended to force the name of local variables - only prop names and class component method names.

Even if this was a desired change, it would have to be behind an option.

[aub]

Thanks for the feedback! I did add a 'checkLocalVariables' option to the rule and a few more tests to check it with various combinations options. It seems to be like it's valuable to make sure that local variables follow the same naming conventions for handlers as ones on an object, and this is something we could use in our own code, specifically for the functional component situation I mentioned before.

[ljharb]

@aub hm, unfortunately since you made a PR from a fork that (i assume) you don't have explicit write access on, but instead have implicit access via org ownership or similar, I'm unable to force push to your PR branch (this should work, but since virtually everybody makes PRs from their personal fork, it hadn't cropped up as a problem until recently). Could you rebase this down to one commit with the commit message [New] `jsx-handler-names`: add `checkLocalVariables` option, and force push?

[aub]

Closing this in favor of #2474, which is the same change but submitted from a different fork and under a single commit.

[ljharb]

@aub Is there any way you could reopen this and match the sha of the other one?

Opening a second PR permanently pollutes the git graph :-/

[aub]

Ok, I've closed the second PR and I believe I have the commit the way you wanted it.

[ljharb]

Thanks!

[jsphstls]

I was dealing with the same issue that prompted this PR. I no longer use class components and props are often destructured. Without this flag, the rule really does not work. With the flag, I see false positives where handler props are passed through.

const SomeButton = ({ onClick }) => <button onClick={onClick} />

@aub do you have any tips for how to use this flag?