This rule is well thought out and has helped enforce consistency in many codebases.
However, there was one area that concerned me, so I created this issue.

Summary

When defining components, developers can choose to access props either via props.onClick or destructure them like { onClick }.
However, react/jsx-handler-names treats these two approaches differently:

// ✅ No lint errorconstComponent=(props)=><ButtononClick={props.onClick}/>;// ❌ Lint errorconstComponent=({ onClick})=><ButtononClick={onClick}/>;

This rule appears to be intentional (as acknowledged here), but in practice I believe it creates several issues that reduce clarity and developer experience:

Problem

The core issue seems to be that the rule behaves differently based purely on whether props are destructured or not — even though both cases appear to refer to the same underlying value.
This difference in behavior may feel inconsistent and confusing, as destructuring is simply a syntactic convenience that does not alter the meaning or usage of the value.

// ✅ props used directly — no lint errorexportconstComponent=(props)=>{consthandleClick=()=>{props.onClick();console.log("clicked");};return(<><ButtononClick={props.onClick}/><ButtononClick={handleClick}/></>);};// ❌ destructured prop — lint error on `onClick`exportconstComponent=({ onClick})=>{consthandleClick=()=>{onClick();console.log("clicked");};return(<><ButtononClick={onClick}/>      // ⚠️ Lint error here<ButtononClick={handleClick}/></>);

This is just one example, but to avoid this lint error, developers must think about how to rename the destructured prop or avoid naming collisions — something that isn't necessary when usingprops.onClick. This adds extra mental overhead compared to the directprops usage.

Suggestion

I believe it would be helpful for the rule to handle both forms consistently.

Possible resolutions might include:

• Allowing destructured props to avoid triggering the rule, just like direct prop access
• Introducing an option likecheckDestructuredProps: false to let teams configure this behavior
• Or, alternatively, clarifying why destructured props should be treated differently, if that's intentional — in which case, understanding that reasoning could help inform best practices and improve adoption

Thanks for your consideration!

similar issue:#358