-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
fix no-unused-prop-types + async class properties and methods #1093
Conversation
There was an inconsistency with access and storage of the usedPropTypes of a component that would cause propTypes to not be correctly marked as used if more than one prop was used in the body of an async function class property or async class method. Fixes jsx-eslint#1053 --- bug source: First time around - get the parentComponent using utils.getParentComponent() https://github.com/yannickcr/eslint-plugin-react/blob/master/lib/rules/no-unused-prop-types.js#L594 - save off the usedPropTypes array from what component was found. - modify the array with my new used props. - set the new array on the node https://github.com/yannickcr/eslint-plugin-react/blob/master/lib/rules/no-unused-prop-types.js#L638 Note that in this case the node is a MemberExpression - Components#set will then just crawl the parents of the current node (the MemberExpresion) until one was found in the internal this._list. - Because all async FunctionExpressions, ArrowFunctionExpressions, and FunctionDeclaration are treated as components of confidence 0 (not a component). The unusedPropTypes would be attached to this. (Which is usually fine). However, if the component tries to mark a prop as used again, it will read from the parentComponent using utils.getParentComponent() (which in this case will return the class) which does not have the previously used methods. The array would then be modified (created because it doesnt exist), and then set them onto the async arrow function overwriting anything that was previously there. This change just attaches used props to the found component (where the previous usedPropTypes are pulled from) if it exists, otherwise to the current node. --- Squashed: Added test cases for factory methods on classes that return async functions. Added test cases using the default eslint parser and defining an async function in the render method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Does this only happen with the combo of class properties and async functions, or are there test cases with async functions but not class properties we could add?
6587485
to
5829bc8
Compare
It only happens whenever an async function was defined and used props without destructuring inside of a class. I do have a few async methods for the non class property variety. And I just added four more test cases to hit a questionable factory method that returns an async function case. Although I don't see why you'd want to do that, but it's possible. |
// factory functions that return async functions | ||
code: [ | ||
'export class Example extends Component {', | ||
' static propTypes = {', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this also happen if propTypes
are assigned outside the class body (ie, using only stage 4 features)? if so, could we add a test case that uses the default parser instead of babel-eslint
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a few more cases with async functions defined in the render method rather than returned from a separate method, and used the default eslint parser.
The issue was with marking the props as used, not with how the propTypes were defined, so using OG syntax works just fine.
5829bc8
to
9213a99
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
When will this be merged? facing the same issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for that fix and the detailed tests.
@benstepp It appears the merge conflicts still need to be handled before this can be merged |
Would leaving a comment here help this get merged? Having this issue and found that it's alllmost there. Keep up the good work here! 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this needs a rebase
9213a99
to
2348bf4
Compare
I took the liberty of rebasing this - it was pretty tricky. I'll merge once tests pass. |
Having this issue and seeing the fix is already in the master but not released yet... |
There was an incosistency with access and storage of the usedPropTypes
of a component that would cause proptypes to not be correctly marked as
used if more than one prop was used in the body of an async function
class property or async class method.
Fixes #1053
bug source:
First time around
Note that in this case the node is a MemberExpression
(the MemberExpresion) until one was found in the internal this._list.
FunctionDeclaration are treated as components of confidence 0 (not a
component). The unusedPropTypes would be attached
to this. (Which is usually fine).
However, if the component tries to mark a prop as used again, it will
read from the parentComponent using utils.getParentComponent() (which in
this case will return the class) which does not have the previously used
methods. The array would then be modified (created because it doesnt
exist), and then set them onto the async arrow function overwriting
anything that was previously there.
This change just attaches used props to the found component (where the
previous usedPropTypes are pulled from) if it exists, otherwise to the
current node.