react/jsx-no-bind: why refs and arrow functions are allowed?

[alex35mil]

In the 3.x.x this rule was turned on. Reasoning is clear and makes a perfect sense. But this commit doesn't make sense to me. Why refs and arrow functions are allowed, while bind is not? New arrow functions are being created on each re-render and they !== to each other, so what's the point of this rule with this change?

[alex35mil]

Found a PR. But these 2 threads are confusing.

• react/jsx-no-bind: how to pass args from callbacks? #659
• Allow arrow functions in JSX props #782

[ljharb]

@alexfedoseev .bind is incredibly slow, much slower than using an arrow function.

[alex35mil]

@ljharb Got it 👍

Just curious, what about equality check? Since on each re-render we create new function, then all components with such props will be flushed to the DOM. And DOM update is the one of the most expensive operation. (Correct me if I'm wrong in some point).

[ljharb]

That was my previous understanding, but since React has a default shouldComponentUpdate implementation of return true, and since most event handlers are added to a global delegation pool and not attached directly to DOM elements, this isn't actually a performance concern even though it seems like it should be.

[alex35mil]

I see then, thanks for explanation!

[taion]

Given this, is the following guidance still relevant?

Bind event handlers for the render method in the constructor.

Why? A bind call in the render path creates a brand new function on every single render.

If not, it should be removed for the sake of clarity.

[ljharb]

It's still a true statement that can indeed impact performance - just not enough to warrant linter enforcement.

[dalexander01]

I'm still very confused by this. What is the recommended best practice? Should I keep using stateless functions when I have callbacks and use arrow functions in the JSX, or should I use classes and bind in the constructor?

[ljharb]

@dalexander01 either way is good. SFCs are better than stateful components, but use whichever approach fits the component type you have.

[taion]

All else being the same, if the onClick handler needs access to a prop value, is it preferable to bind the handler in a stateless component (onClick={() => props.onSelect(props.eventKey)}) or to use a bound method in a stateful component?

[ljharb]

imo, a stateless component is so much better than a stateful one, that any potential tiny performance difference (and I suspect there's none) is absolutely worth it - iow, stateless.

[taion]

Okay, so in other words, the rule is: when using a stateful component, bind handlers in the constructor, but prefer using a stateless component with arrow functions for handlers in render?

[ljharb]

Well stated, yes :-)