Rule proposal: disallow arrow functions for defining stateless functional components

[lencioni]

Since arrow functions don't have names, and it is useful for React components to have names, it would be nice if there was a rule that enforced using named functions for stateless functional components and prevented using arrow functions for this case.

Good:

function Thing({ prop, anotherProp }) {
  return <div>{prop}{anotherProp}</div>;
}

Bad:

const Thing = ({ prop, anotherProp }) => {
  return <div>{prop}{anotherProp}</div>;
}

[ljharb]

👍

[justjake]

👍

[wyattdanger]

👍

[goatslacker]

LGTM

[yannickcr]

Is it really useful since AFAIK Babel will keep compiling both as named components ?

The display-name rule should already prevent you from making "anonymous" components.

[ljharb]

@yannickcr this assumes one is always using Babel to compile arrow functions, which is not necessarily the case.

[lencioni]

Is it really useful since AFAIK Babel will keep compiling both as named components ?

Ah, interesting. I tried it out in the REPL and you are correct about Babel compiling both as named functions.

However, in addition to what @ljharb mentioned, in the project I am working in (which uses Babel), when I look in the React inspector I see components that are arrow functions called <StatelessComponent> and components that are named functions called by the name of the function. I checked out the transpiled code and, at least with the version and configuration we are using, the arrow function is transpiled to an anonymous function.

Even if this were not the case, I can imagine that some people would simply want to enforce consistency of always using either named functions or arrow functions across their codebase as a stylistic choice.

[yannickcr]

@ljharb you're right, you may even not need a transpiler at all if you're not using JSX.

@lencioni maybe a difference between Babel 5 and 6 ? The REPL is still using Babel 5. The <StatelessComponent> case is exactly the sort of things display-name should prevent. But maybe there is some case where the acceptTranspilerName option is assuming that Babel will assign a name when in reality this is not the case. I will do some tests.

But yes, it makes sense to have a rule to enforce consistency for stateless components.

[tleunen]

Currently, arrow functions have names if they are assigned to a variable. They automatically take the name of the variable. It's currently the case in Canary for example, so I searched if it's something that will change in the future but couldn't find anything. I found this article showing each case though http://www.2ality.com/2015/09/function-names-es6.html.

So even without using Babel, it seems the only bad case is to export the arrow function without assignment.

[golopot]

This is handled by #2414

[ljharb]

Indeed, this is now handled by the function-component-definition rule.