-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Add fix for prefer-stateless-function #1229
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
Conversation
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.
Please add some test cases that use the default parser as well, so it's not just testing babel-eslint.
@@ -2,6 +2,8 @@ | |||
|
|||
Stateless functional components are simpler than class based components and will benefit from future React performance optimizations specific to these components. | |||
|
|||
**Fixable:** This rule is automatically fixable using the `--fix` flag on the command line. |
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'm not sure this is accurate unless it can fix all errors that the rule warns on.
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.
Yes, you are right. We should postpone this line until the rule is fully fixable.
var isRender = name === 'render'; | ||
return !isDisplayName && !isPropTypes && !contextTypes && !isUselessConstructor && !isRender; | ||
return !( |
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 kind of feel like the prior form was more readable; a bunch of "nots" seems easier to understand to me than a bunch of positives, negated
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.
Agree ;) I've saved couple characters, but the readability of previous one is much better.
(This is awesome, btw, thanks!) |
'}' | ||
].join('\n'), | ||
output: [ | ||
'let Foo = (props) => {};' |
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.
Why does the fixer output an arrow function for SFCs?
This will run afoul of, for example, the airbnb style guide, which only allows named functions as SFCs. If we instead defaulted to a normal named function here, other rules would be able to convert it to an arrow.
Also, converting from a class
declaration to an expression isn't always a safe change; the only safe replacement for class
is a function
declaration (which will be an expression when in expression position).
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.
Yep!
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.
This LGTM! It would be ideal to also support auto fixing React.createClass instances as well, tho.
@ljharb Yes, I think it's doable by me. Let me look into this in the next week. For me both options are ok. |
Since this needs to wait for other collabs to review before merging, I'd say we'll play it by ear. |
' ', | ||
' return <div>{props.test}</div>;', | ||
'}', | ||
'Foo.propTypes={foo: PropTypes.func};', |
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 would like to see an empty line between the closing }
and the Foo.propTypes
assignment. It's a personal taste though. What do others think?
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.
That seems like something another rule should be handling.
I ran this on my code-base which only uses class syntax, no stateless function components at all, and it seems to work pretty well. I found one issue where the I added a tiny comment about a syntactical preference, but it's very personal: https://github.com/yannickcr/eslint-plugin-react/pull/1229/files#r119805697 |
EDIT: You can ignore this comment. I checked the source of the actual rule, and it doesn't deal with This doesn't seem to handle the case of For instance, class MyComponent extends Component {
render() {
<div>{this.context.thing}</div>
}
} could be re-written as function MyComponent(props, context) {
return (
<div>{context.thing}</div>
);
} I'd like to see a test case that uses |
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.
This needs a rebase and then a rereview
@RiddleMan if you're able to rebase this, it'd be great to land it :-) |
I rebased this. https://github.com/golopot/eslint-plugin-react/tree/pr-1229 . (Commits are squashed and the three files are merged to one.) |
@RiddleMan would you mind checking the "allow edits" box on the RHS of the PR? |
@ljharb I'm worried that I don't have such checkbox on the RHS. The explanation is simple... accidentally I removed my fork :/ Can we just create a new one with golopot's changes? Or anything you find fit. |
@RiddleMan oof, that's unfortunate. you could try recreating the fork and see what happens? |
@golopot i suppose we'll need to make a new PR. Mind creating one from your branch? |
ping @golopot |
I've rebased this and added the correct Help is welcome. |
It'd be great if someone wants to file a new PR that solves this; but unfortunately this one is unrecoverable. |
Fixes #1096.
I've managed to accomplish this fix! Yay!
Also, I had tested this on my codebase and worked nicely.
I've added one module for indentation detection because I'd like to keep original formatting of the elements.
Unfortunately, This solution works only for ES6 components. This code does not handle ES5 ones, but I created a possibility to add later fix for those too.
I'm open for the suggestions :)