Proposal new rule : jsx-no-lambda

[VincentLanglet]

Since tslint is going to be deprecated in favor of eslint and typescript-eslint. Some people (like me) are going to move from tslint-react to eslint-plugin-react.

I think the only missing rule in eslint-plugin-react is the jsx-no-lambda rule.

Creating new anonymous functions (with either the function syntax or ES2015 arrow syntax) inside the render call stack works against pure component rendering. When doing an equality check between two lambdas, React will always consider them unequal values and force the component to re-render more often than necessary.
Rule options: none

I think it is a good one to add.

[ljharb]

I wouldn’t want to use the inaccurate name “lambda”, but a rule that prevents passing render-path created functions as props to custom components only seems interesting (although it would overlap with jsx-no-bind a bit)

[VincentLanglet]

Indeed, I didn't see the jsx-no-bind exists already.

[KingDarBoja]

The original jsx-no-bind rule at tslint-react states:

Forbids function binding in JSX attributes. This has the same intent as jsx-no-lambda in helping you avoid excessive re-renders.

So pretty much redundant IMO.

[vdpdev]

@KingDarBoja as i understand - jsx-no-lambda is redundant as you say. What should i use to have eslint's alert about lambda in jsx/tsx?

[vdpdev]

@KingDarBoja Never mind. I've found that react/jsx-no-bind from yannickcr/eslint-plugin-react does next: Prevents usage of Function.prototype.bind and arrow functions in React component props which is totally the same what @VincentLanglet wants. But it was no obvious that react/jsx-no-bind will argue on arrow functions in jsx/tsx.

[KingDarBoja]

@KingDarBoja as i understand - jsx-no-lambda is redundant as you say. What should i use to have eslint's alert about lambda in jsx/tsx?

Just noticed until now I put the wrong quote from docs. I updated my previous comment. Thank you 💯