eslint-plugin-react

-plugin-react/issues/233... Not everyone works on giant teams where global settings that aren't part of the project become a nightmare for compatibility. We have a very small team with often just one developer doing most of the work on a project.

ay that that has become a blanket concern that people blindly repeat, no matter what the actual performance concerns are for a given component, and that some of the possible origins for that concern are likely no longer an issue with modern JS engines. For example, I know that AirBnB's ESLint config, which is very popular, turns on the "react/jsx-no-bind" rule [0] by default. This rule flat-out forbids using `fn.bind()` inside of JSX constructs, but does not take into account anything like how the component is actually being used. A component rendered once at the top level of an app is going to have a vastly different performance profile than a nested component in the middle of a hot UI code path. I've seen learners who are still trying to grasp the basics of React being told "oh, you should never use an arrow function in `render()`, that's slow". Even if that's true, that's also not the advice the learner needs at that time. The most common example of this I see is someone who wants to pass a parameter to a callback, and they do: onClick={this.handleClick("stuff")} That of course fails, because the click handler is being called immediately during rendering. The simplest fix for this is to just make it an arrow function that closes over the call: onClick={() => this.handleClick("stuff")} Even if that isn't the most absolutely performant approach, it _works_, it's simple for the learner to implement, and it solves their immediate problem. They don't _need_ to be worrying about perf at that level of understanding. Now, as you said: _if_ you do have an extremely hot and perf-sensitive UI path, then yes, it's worth worrying about the details like this. But, the point of the article is that the React community has gotten in the habit of blindly repeating "DON'T DO THAT EVER!!!!!", when the reality is much more nuanced: "Don't worry about that.... _yet_". To specifically answer your last aspect: Let's say you've got a child component that implements a click handler like this: handleClick = () => { this.props.doStuff(this.props.id, this.state.someValue); } In that example, `this.props.doStuff` isn't actually affecting rendering. So, if the parent component passes in a new function reference for `props.doStuff`, the component doesn't actually need to re-render - the click handler would behave the same way regardless. [0] https://github.com/yannickcr/eslint-plugin-react/blob/master...