Rule proposal: Warn against using an arrow function/anon fn when declaring a component

[tleunen]

Component should be named, and arrow functions are anonymous functions, so they produce unnamed components.

Even if Babel currently transforms an anonymous function into a named function, and even if Chrome currently set a name (fn.name) when assigning it to a variable, I believe it would be best to add a rule to warn against the use of arrow functions.

For example, when using jsdom and enzyme to test components built with arrow functions, we can get errors messages like this one because the component name was not set: expected the node in <??? /> to have....

So having a specific rule rule would help waning against arrow and anonymous function in general would help for this.

[ljharb]

Perhaps it could be more generic and be configurable to require/allow specific function kinds for SFCs.

[gaearon]

Even if Babel currently transforms an anonymous function into a named function, and even if Chrome currently set a name (fn.name) when assigning it to a variable, I believe it would be best to add a rule to warn against the use of arrow functions.

Why? Per spec, the name will be assigned, so it’s fine.
(FWIW the official position is that arrow functions work well as components, and we might use this pattern in the documentation.)

[ljharb]

@gaearon but in practice it is not always assigned. In general, explicit > implicit, and a linter rule to require explicit names by disallowing arrow functions is appropriate.

[gaearon]

Can you help me understand in which situations it wouldn’t get assigned?

[ljharb]

@gaearon In the Babel repl, this function has no name:

export default (props) => {
  return <div {...props} />;
}

which thus would necessitate:

const Foo = (props) => {
  return <div {...props} />;
};
export default Foo;

but export-defaulting one thing only from a file inline is also a best practice according to the Airbnb styleguide.

In node 4 and later, if you do const foo = () => {};, foo.name is the empty string - I don't know the exact range of node and Chrome versions that this applies to, since the latest Chrome does have name inference, but there are many implementations in the wild that support arrow functions but not name inference.

[bkozera]

+1 from me.

Reasons:

• Airbnb suggests that in their guide (unfortunately not explaining why)
• Makes it easy to have consistency when writing stateless components across team (could have also opposite version forcing fat arrow)
• There is a bug in jest (actually in istambul) where jest --coverage is sometimes failing. Changing to function from fat arrow did solve that for us.

[TheTFo]

+1, I got caught by the Jest bug pointed out by bkozera, had to rewrite components to not use the fat arrow