Return to Answer

Why shouldn't JSX props use arrow functions or bind?

Mostly, because inline functions can break memoization of optimized components:

Traditionally, performance concerns around inline functions in React have been related to how passing new callbacks on each render breaks shouldComponentUpdate optimizations in child components. (docs)

It is less about additional function creation cost:

Performance issues with Function.prototype.bind got fixed here and arrow functions are either a native thing or are transpiled by babel to plain functions; in both cases we can assume it’s not slow. (React Training)

I believe people claiming function creation is expensive have always been misinformed (React team never said this). (Tweet)

When is the react/jsx-no-bind rule useful?

You want to ensure, that memoized components work as intended:

• React.memo (for function components)
• PureComponent or custom shouldComponentUpdate (for class components)

By obeying to this rule, stable function object references are passed. So above components can optimize performance by preventing re-renders, when previous props have not changed.

How to solve the ESLint error?

Classes: Define the handler as method, or class property for this binding.
Hooks: Use useCallback.

Middleground

In many cases, inline functions are very convenient to use and absolutely fine in terms of performance requirements. Unfortunately, this rule cannot be limited to only memoized component types. If you still want to use it across-the-board, you could e.g. disable it for simple DOM nodes:

rules: { "react/jsx-no-bind": [ "error", { ignoreDOMComponents: true } ], } const Comp = () => <span onClick={() => console.log("Hello!")} />; // no warning 

Why shouldn't JSX props use arrow functions or bind?

Mostly, because inline functions can break memoization of optimized components:

Traditionally, performance concerns around inline functions in React have been related to how passing new callbacks on each render breaks shouldComponentUpdate optimizations in child components. (docs)

It is less about additional function creation cost:

Performance issues with Function.prototype.bind got fixed here and arrow functions are either a native thing or are transpiled by babel to plain functions; in both cases we can assume it’s not slow. (React Training)

I believe people claiming function creation is expensive have always been misinformed (React team never said this). (Tweet)

When is the react/jsx-no-bind rule useful?

You want to ensure, that memoized components work as intended:

• React.memo (for function components)
• PureComponent or custom shouldComponentUpdate (for class components)

By obeying to this rule, stable function object references are passed. So above components can optimize performance by preventing re-renders, when previous props have not changed.

How to solve the ESLint error?

Classes: Define the handler as method, or class property for this binding.
Hooks: Use useCallback.

Middleground

In many cases, inline functions are very convenient to use and absolutely fine in terms of performance requirements. Unfortunately, this rule cannot be limited to only memoized component types. If you still want to use it across-the-board, you could e.g. disable it for simple DOM nodes:

rules: { "react/jsx-no-bind": [ "error", { "ignoreDOMComponents": true } ], } const Comp = () => <span onClick={() => console.log("Hello!")} />; // no warning 

Why shouldn't JSX props use arrow functions or bind?

Mostly, because inline functions can break memoization of optimized components:

Traditionally, performance concerns around inline functions in React have been related to how passing new callbacks on each render breaks shouldComponentUpdate optimizations in child components. (docs)

It is less about additional function creation cost:

Performance issues with Function.prototype.bind got fixed here and arrow functions are either a native thing or are transpiled by babel to plain functions; in both cases we can assume it’s not slow. (React Training)

 

I believe people claiming function creation is expensive have always been misinformed (React team never said this). (Tweet)

When is the react/jsx-no-bind rule useful?

You want to ensure, that memoized components work as intended:

• React.memo (for function components)
• PureComponent or custom shouldComponentUpdate (for class components)

By obeying to this rule, stable function object references are passed. So above components can optimize performance by preventing re-renders, when previous props have not changed.

How to solve the ESLint error?

Classes: Define the handler as method, or class property for this binding.
Hooks: Use useCallback.

Middleground

In many cases, inline functions are very convenient to use and absolutely fine in terms of performance requirements. Unfortunately, this rule cannot be limited to only memoized component types. If you still want to use it across-the-board, you could e.g. disable it for simple DOM nodes:

rules: { "react/jsx-no-bind": [ "error", { ignoreDOMComponents: true } ], } const Comp = () => <span onClick={() => console.log("Hello!")} />; // no warning 

Why shouldn't JSX props use arrow functions or bind?

Mostly, because inline functions can break memoization of optimized components:

Traditionally, performance concerns around inline functions in React have been related to how passing new callbacks on each render breaks shouldComponentUpdate optimizations in child components. (docs)

It is less about additional function creation cost:

Performance issues with Function.prototype.bind got fixed here and arrow functions are either a native thing or are transpiled by babel to plain functions; in both cases we can assume it’s not slow. (React Training)

I believe people claiming function creation is expensive have always been misinformed (React team never said this). (Tweet)

When is the react/jsx-no-bind rule useful?

You want to ensure, that memoized components work as intended:

• React.memo (for function components)
• PureComponent or custom shouldComponentUpdate (for class components)

By obeying to this rule, stable function object references are passed. So above components can optimize performance by preventing re-renders, when previous props have not changed.

How to solve the ESLint error?

Classes: Define the handler as method, or class property for this binding.
Hooks: Use useCallback.

Middleground

In many cases, inline functions are very convenient to use and absolutely fine in terms of performance requirements. Unfortunately, this rule cannot be limited to only memoized component types. If you still want to use it across-the-board, you could e.g. disable it for simple DOM nodes:

rules: { "react/jsx-no-bind": [ "error", { ignoreDOMComponents: true } ], } const Comp = () => <span onClick={() => console.log("Hello!")} />; // no warning 

Is the react/jsx-no-bind ESLint rule still relevant?

tldr: In most cases React (Fiber) is fast enough, so this rule is neglectable.

A more environment-specific approach: Is your current app performance sufficient? If the answer is "no", then measure before and after a refactoring (e.g. function memoization) - don't rely on premature optimization.

There is also no need to speculate about function creation cost and performance of closures.

Who still might profit?

####Memoized components ✔ Components wrapped by React.memo or PureComponent use reference equality checks on props to determine re-renders. A memoized function provides a stable object reference and can prevent a re-render. If this component is costly to render, performance might benefit (recap tldr).

DOM nodes ✖

There is not much to reconcile for simple DOM nodes.

Non-memoized components ✖

A non-memoized component re-renders every time, state or props change in one of its ancestors.

###Solutions

1. Disable the rule. Don't bother, until performance suffers (subjective to app).

2. Adjust rule to ignore warnings for DOM nodes as kind of compromise:

rules: { "react/jsx-no-bind": [  "error",  {  ignoreDOMComponents: true, ignoreRefs: true,  },  ], }, const Comp = () => <span onClick={() => console.log("Hello!")} />; // no warning 

3. Use performance optimizations like useCallback for Hooks. Useful FAQ entries:

• Is it safe to omit functions from the list of dependencies?
• How to avoid passing callbacks down?

Why shouldn't JSX props use arrow functions or bind?

Mostly, because inline functions can break memoization of optimized components:

Traditionally, performance concerns around inline functions in React have been related to how passing new callbacks on each render breaks shouldComponentUpdate optimizations in child components. (docs)

It is less about additional function creation cost:

Performance issues with Function.prototype.bind got fixed here and arrow functions are either a native thing or are transpiled by babel to plain functions; in both cases we can assume it’s not slow. (React Training)

I believe people claiming function creation is expensive have always been misinformed (React team never said this). (Tweet)

When is the react/jsx-no-bind rule useful?

You want to ensure, that memoized components work as intended:

• React.memo (for function components)
• PureComponent or custom shouldComponentUpdate (for class components)

By obeying to this rule, stable function object references are passed. So above components can optimize performance by preventing re-renders, when previous props have not changed.

How to solve the ESLint error?

Classes: Define the handler as method, or class property for this binding.
Hooks: Use useCallback.

Middleground

In many cases, inline functions are very convenient to use and absolutely fine in terms of performance requirements. Unfortunately, this rule cannot be limited to only memoized component types. If you still want to use it across-the-board, you could e.g. disable it for simple DOM nodes:

rules: { "react/jsx-no-bind": [ "error", { ignoreDOMComponents: true } ], } const Comp = () => <span onClick={() => console.log("Hello!")} />; // no warning