Update jsx-no-bind.md #1231
Update jsx-no-bind.md #1231
Conversation
| @@ -1,6 +1,6 @@ | |||
| # No `.bind()` or Arrow Functions in JSX Props (react/jsx-no-bind) | |||
|
|
|||
| A `bind` call or [arrow function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions) in a JSX prop will create a brand new function on every single render. This is bad for performance, as it will result in the garbage collector being invoked way more than is necessary. | |||
| A `bind` call or [arrow function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions) in a JSX prop will create a brand new function on every single render. This is bad for performance, as it will result in the garbage collector being invoked way more than is necessary. It may also cause unnecessary re-renders if a brand new function is passed as a prop to a component that uses reference equality check on the prop to determine if it should update. | |||
There was a problem hiding this comment.
We should probably also add ", which includes arrow functions assigned in class properties" or something similar.
There was a problem hiding this comment.
@ljharb not quite sure what you mean here. Having the arrow function assigned as a class property is the recommended approach.
There was a problem hiding this comment.
It most certainly is not the recommended approach.
That said, it does avoid the creation of functions in the render path, so you're right that it doesn't belong here.
There was a problem hiding this comment.
** recommended approach if one needs to preserve the this of a component, which is not always needed. Or is that otherwise? Yes, as for rendering, arrow functions that are not created in render won't trigger a re-render so this description should be fine.
There was a problem hiding this comment.
The recommended approach is a constructor-bound instance method, so the meat of the function can be optimized.
There was a problem hiding this comment.
@ljharb what do you mean by "the meat of the function can be optimized."? Can you point me to some resource that explains this?
There was a problem hiding this comment.
I don't have a resource to point to; I just mean that the bulk of the code can live on a shared prototype method, that is thus invoked many times (and shared across all instances), so that can get optimized - then the only part that's "one per instance" is the bind-proxy. With the class property approach, your function (which has, say, 6 lines of code) gets recreated for every instance, so the engine can't optimize those 6 lines - since every instance has a distinct copy of those 6 lines of code.
No description provided.