It would be useful to turn off the displayName rule for stateless components. While I want all components declared using a ES6 class syntax or createClass to have a name, there's instances when it's useful to anonymously wrap a component using a quick arrow function syntax. For instance:
function wrapCustomComponent(Component, extendedProps) {
return (props) => {
let mergedProps = Object.assign({}, extendedProps || {}, props.rowData);
return <Component {...mergedProps} />;
};
}
The component could be assigned to a variable to give it a name, but that requires creating extra variables just to hold it temporarily before it gets returned from a function.
The proper solution here is to use a named function instead of an arrow function. There's no need to use an arrow here - they're not just a cure-all for "short functions".
That's one school of thought, to name everything to improve debugging. But that also reduces readability. Part of why arrow functions and anonymous functions were created was to improve readability. In cases where names add little to no meaning, I would rather trade-off the slight advantage in debugging for improved readability.
Perhaps that wasn't the best example. An even shorter example might be:
return (props) =>
<DataLoader {...dataProps}>
<Component {...props}} />
</DataLoader>;
Yes, this can be written as:
return function WrappedComponent(props) {
return <DataLoader {...dataProps}>
<Component {...props}} />
</DataLoader>;
};
But that's less readable.
The difference is the same between the school of thought that you should never have anonymous functions and should always use names, even if they are arbitrary, such as using iteratee as the name of functions passed to map/reduce, and the school of thought that says to make names have meaning and use anonymous functions instead of arbitrary named ones.
My proposal is simply to create a less opinionated linter rule that can apply to both schools of thought. For now, I've simply disabled the rule each time I use that idiom.
I find those examples much more readable than the arrows. A React component is very different from a HOF callback, and having a name is very important. Arrow functions were created to replace callbacks - not to replace normal functions.
If you insist on ignoring the decades of best practices that say to always name meaningful functions (like React components) then disabling the rule at the usage site (or overall) is the correct approach.
Most helpful comment
That's one school of thought, to name everything to improve debugging. But that also reduces readability. Part of why arrow functions and anonymous functions were created was to improve readability. In cases where names add little to no meaning, I would rather trade-off the slight advantage in debugging for improved readability.
Perhaps that wasn't the best example. An even shorter example might be:
Yes, this can be written as:
But that's less readable.
The difference is the same between the school of thought that you should never have anonymous functions and should always use names, even if they are arbitrary, such as using
iterateeas the name of functions passed to map/reduce, and the school of thought that says to make names have meaning and use anonymous functions instead of arbitrary named ones.My proposal is simply to create a less opinionated linter rule that can apply to both schools of thought. For now, I've simply disabled the rule each time I use that idiom.