Skip to content

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

Closed
wants to merge 8 commits into from
Closed

Add fix for prefer-stateless-function #1229

wants to merge 8 commits into from

Conversation

RiddleMan
Copy link

@RiddleMan RiddleMan commented May 30, 2017

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 :)

@RiddleMan RiddleMan changed the title Add fix for prefer-stateless-function #1096 Add fix for prefer-stateless-function May 30, 2017
Copy link
Member

@ljharb ljharb left a 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.
Copy link
Member

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.

Copy link
Author

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 !(
Copy link
Member

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

Copy link
Author

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.

@ljharb
Copy link
Member

ljharb commented May 30, 2017

(This is awesome, btw, thanks!)

'}'
].join('\n'),
output: [
'let Foo = (props) => {};'
Copy link
Member

@ljharb ljharb May 31, 2017

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).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep!

Copy link
Member

@ljharb ljharb left a 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.

@RiddleMan
Copy link
Author

@ljharb Yes, I think it's doable by me. Let me look into this in the next week.
Do you think, that we should merge what we have here and then add support for createClass?
Or should I add fixer for that in a scope of this PR?

For me both options are ok.

@ljharb
Copy link
Member

ljharb commented Jun 1, 2017

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};',
Copy link
Contributor

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?

Copy link
Member

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.

@jseminck
Copy link
Contributor

jseminck commented Jun 2, 2017

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 prefer-stateless-function rule doesn't detect well, I will create a ticket for that.

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

@deecewan
Copy link
Contributor

deecewan commented Jul 6, 2017

EDIT: You can ignore this comment. I checked the source of the actual rule, and it doesn't deal with context either, I don't think. It definitely could, but that's a separate issue.

This doesn't seem to handle the case of context.

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 context, even if it doesn't support fixing context.

Copy link
Member

@ljharb ljharb left a 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

@ljharb
Copy link
Member

ljharb commented Dec 27, 2018

@RiddleMan if you're able to rebase this, it'd be great to land it :-)

@golopot
Copy link
Contributor

golopot commented Jun 29, 2019

I rebased this. https://github.com/golopot/eslint-plugin-react/tree/pr-1229 . (Commits are squashed and the three files are merged to one.)

@ljharb
Copy link
Member

ljharb commented Aug 19, 2019

@RiddleMan would you mind checking the "allow edits" box on the RHS of the PR?

@RiddleMan
Copy link
Author

@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.

@ljharb
Copy link
Member

ljharb commented Aug 31, 2019

@RiddleMan oof, that's unfortunate. you could try recreating the fork and see what happens?

@ljharb
Copy link
Member

ljharb commented Dec 30, 2019

@golopot i suppose we'll need to make a new PR. Mind creating one from your branch?

@ljharb
Copy link
Member

ljharb commented Aug 9, 2020

ping @golopot

ljharb pushed a commit to ljharb/eslint-plugin-react that referenced this pull request Oct 16, 2020
@ljharb
Copy link
Member

ljharb commented Oct 16, 2020

I've rebased this and added the correct output results here: https://github.com/ljharb/eslint-plugin-react/tree/pr-1229. Test results are here: https://github.com/ljharb/eslint-plugin-react/runs/3657318331.

Help is welcome.

@ljharb ljharb marked this pull request as draft October 16, 2020 07:40
ljharb pushed a commit that referenced this pull request Sep 20, 2021
@ljharb
Copy link
Member

ljharb commented Jul 20, 2024

It'd be great if someone wants to file a new PR that solves this; but unfortunately this one is unrecoverable.

@ljharb ljharb closed this Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

Add fix to prefer-stateless-function
5 participants