React/declarations for function components

[stefan-wullems]

This is just draft of how I would like it to work. Any feedback would be much appreciated.

This pull request was inspired by #690

Tasks:

• warn when component is not defined in the preferred way
• Autofix component to preferred component
• able to configure preference both named and unnamed components and autofix both accordingly
• support autofix for typescript
  • handle components with type arguments
  • ignore function expressions and arrow functions of which the variable declaration is explicitly typed
• docs

[ljharb]

Thanks, this is a great start!

It'd be really nice if this could be autofixable. Things to watch out for in the fixers include:

• any usage of this directly inside the component, or inside an arrow function (ie, not wrapped by another normal function), should prevent the autofix
• if the component is an arrow function, and has an inferred name, that should be the name of the function expression. if it doesn't, then it should become an anonymous function expression
• if the component is a function declaration, it should not be autofixed into an arrow expression
• if the component is a function expression, the explicit name should match whatever the inferred name of the arrow function will eventually be - or else it should not run an autofix.

[stefan-wullems]

Does autofix take typescript into account at all? I imagine autofixing a functional component that is defined like so:

const Component: React.FC<Props> = (props) => {
   return null
} 

would lead to unintentional side effects. Should eslint-plugin-react care about this? @ljharb

[ljharb]

That’s a fair point; if the types can be fixed, great, if not, best to skip auto fixing entirely when there’s type annotations.

[stefan-wullems]

I will start writing the documentation once I have some certainty that it now works the way you are okay with @ljharb

[ljharb]

Thanks, this looks great. Let's get that documentation written.

[ljharb]

@Stefanwullems tests are failing.

[stefan-wullems]

@ljharb If everything is allright, let's get this merged??

[ljharb]

@Stefanwullems this needs to be rebased on latest master, ideally squashed down to one commit, and all conflict markers removed (look for <<<<<, >>>>>, and =====).

[stefan-wullems]

@ljharb I have no idea how to squash so it would be perfect if you or someone else can take is off my hands before I explode something.

[ljharb]

I’m talking about git rebase; i can certainly try to do it for you but you have more context on the change than i do.

[stefan-wullems]

I’m talking about git rebase; i can certainly try to do it for you but you have more context on the change than i do.

@ljharb I think I rebased it but I have no idea if I did it right.

[stefan-wullems]

@ljharb I think it's ready