Rule to forbid calling components as functions?

[FezVrasta]

Sometimes inexperienced developers define functions that return jsx that would better work as components.

example:

const App = () => {
  function renderIcon() {
    return <i />;
  }
  
  return (
    <div>{renderIcon()}</div>
  );
}

I’d like a rule to forbid this behavior and instead suggest to convert it to a proper competent called with jsx.

this allows React to optimize its re-renders.

[AriPerkkio]

At least in the example App component the internal renderIcon function should not be converted to React component. That would violate react/no-unstable-nested-components and produce even worse performance.

But sure, moving it outside App component and declaring as proper React component would likely be better.

[FezVrasta]

Hi, yeah of course it would need to be moved to the root scope.

Is there any rule that allows to enforce what I'm describing already?

[ljharb]

In this case it would work better as just inline jsx, and there’s no real harm from putting that in the render function. Do you have some examples that are actually problematic?

[FezVrasta]

That would work too @ljharb , it really depends case by case, sometimes a component makes more sense for readability or to keep the input/output clearer.

I think the rule should just forbid the usage I showed above.

[ljharb]

I don't think that's react-specific, though - that's basically "a function, created inside a function body, invoked in the function body, and not otherwise referenced". I'd suggest proposing a core eslint rule if that's something that you think should be warned on, but there are legit use cases for this (scoping, the lack of do expressions, etc) so i'm not sure if it'd be accepted.

[FezVrasta]

The issue here is React specific because the problem is the usage of a function instead of a component, making it impossible for the reconciler to apply its optimizations.

[ljharb]

Right, but this case shouldn't BE a component - and there's no actual advantage to making it one.

[AriPerkkio]

I think this rule would still be useful. I've also seen these cases where developers create additional functions just to reduce the length of return statement's JSX block. Inline JSX or converting the function into React component would be better.

For implementation I think this rule should start from CallExpressions inside JSX. Then look for scope to see if this function was declared within the scope.
This would prevent falsely flagging renderProps pattern.

01 | function renderFooter() {
02 |     return <div />;
03 | }
04 | 
05 | function MyComponent({ renderHeader }) {
06 |     return (
07 |         <>
08 |             {renderHeader()} // OK
09 |             <div>My Component</div>
10 |             {renderFooter()} // Report as error
11 |         </>
12 |     )
13 | }

Line 8 should not be reported as error since renderHeader is not declared in the scope. Line 10 should be since in its scope there is FunctionDeclaration for renderFooter present. I don't think this rule should care whether function is declared inside component body or not.

So would this rule be "In JSX, prefer React components or elements instead of plain functions returning JSX"?

[ljharb]

I'm still not clear on the downsides here.

In that example, repeating <div /> inline, or storing it in a variable and repeating the variable, would be identical. Making a separate Footer component and repeating it twice would be identical - except that it'd have an extra level on the component stack (which, to be fair, is negligible, but if anything it's a vote against it).

[andlbrei]

Kent C. Dodds has a blog post about this.
Maybe it contains some information relevant to this issue: https://kentcdodds.com/blog/dont-call-a-react-function-component

[ljharb]

That blog post is correctly describing why you shouldn't call a react component directly as a function.

It is not, however, talking about calling a non-component function that returns JSX - typically called a "render function", or used as a prop, a "render prop".

I don't think it makes sense to have a rule forbidding this. If someone wants to share code examples that are legitimately problematic - as opposed to just "maybe that's not the best way to organize that code" - I'm sure I'd be convinced to reopen this.