Thanks for the reply and the details. Let me see if I can add more context to the overall discussion, and why Ryan wrote the article in the first place.

First, the author of the article is Ryan Florence. He's a very well-known name in the React community, as he's co-author of React-Router, and co-owner of the React Training company. He makes a living teaching React to developers at different companies. I don't always agree with _everything_ he says, but he has a _lot_ of personal experience using React, and has seen a wide variety of ways that people are learning and using React in the real world. So, I don't think it's fair to say that he's "generalising his own limited experience".

Second, I would say that Ryan's post isn't trying to argue that you should never-ever worry about creating functions in `render()`. It _is_ trying to say 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...