Require function declaration for named components

[Richienb]

Fixes #32

[sindresorhus]

Hmm, this will disallow using arrow functions for components at all though. I mostly use function declaration for exported components. It's nice to be able to define using arrow function for non-exported components. Thoughts?

[Richienb]

Recently, I've been shifting away from overusing const foo = () => {} because it just defines a function which is what function was built for anyways: function foo() {}. It's the same reason why I defined these functions as actual functions.

Arrow functions are for functions that can fit entirely on one line and that is rarely an entire React component.

[Richienb]

Given this, adding brackets around components that are returned may become more of an annoyance since we would no longer need to make it explicitly clear where our components are since it would be implied by the return keyword. But that's for another issue.

[sindresorhus]

I agree with your reasoning. Let's try it out.

[Primajin]

unsolicited opinion here 😉
I am personally going with arrow functions by default for all the things, and only resort to function when I have a clear need for things like this or super

[jonahsnider]

One thing that I've noticed while updating code to comply with this rule is you can no longer effectively use the TypeScript types provided by @types/react. This bothered me enough to revert the rule change in my own XO config.

Take this snippet for example:

import type {FC} from 'react';

interface Props {
	href?: string;
}

const Button: FC<Props> = props => (
	<a href={props.href} className='btn'>
		<p>{props.children}</p>
	</a>
);

export default Button;

How should this code be updated?

You can turn const Button into export default function Button, but since it's not a variable you can't use FC<T>.
You need to explicitly write the return type and update the Props interface to include the children property which FC<T> adds.

[Richienb]

Yes, that's a legitimate use case. We'd need to detect whether TypeScript types are used on the variable which may be difficult. Perhaps it is easier to disable the rule or make it much more lenient?

[Primajin]

Did you do a performance comparison? Could arrow functions be optimized way more by the JIT than regular functions?

[jonahsnider]

Arrow functions perform very slightly better since they don't need to allocate a this context. In practice this doesn't matter since almost every React app is getting passed through a bundler pipeline that rewrites code to be ES5 compatible.