Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration of react/jsx-no-bind allows to use arrow functions, while the style guide prohibits it #2255

Open
speicus opened this issue Jul 4, 2020 · 3 comments

Comments

@speicus
Copy link

speicus commented Jul 4, 2020

The current configuration of react/jsx-no-bind allows to use arrow functions as event handlers (and ignores the use of bind in DOM components too): https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/rules/react.js#L104

image

However, here's what the style guide has to say bout this:


image


  1. I agree with the guide's argument and belive that it would be best to update the rule configuration to match it. Using arrow function to initialize an event handler creates a brand new function on each render same as bind() does, which can lead to unnecessary re-renders.

  2. To be honest, I'd even turn ignoreDOMComponents to false too — it is unclear why DOM components deserve a different treatment. I'd say the reasoning from the style guide fully applies to them too.

  3. If, however, there is some reasoning behind these exceptions — then the style guide should probably reflect it.

@speicus speicus changed the title Configuration of react/jsx-no-bind allows to use arrow functions, while the style guide strictly prohibits it Configuration of react/jsx-no-bind allows to use arrow functions, while the style guide prohibits it Jul 4, 2020
@ljharb
Copy link
Collaborator

ljharb commented Jul 4, 2020

  1. Based on the coding patterns inside airbnb, tightening the rule would be too noisy and restrictive. There's no reason the guide and the linter have to be completely identical; it's totally fine if some things are left to human discernment. (Separately, .bind() is much slower than arrow functions are; the performance hit for using new arrow functions is insignificant in comparison)

  2. DOM components don't need the same restriction regardless because the hazard is custom components rerendering too much; that's impossible for DOM elements.

@vicasas
Copy link

vicasas commented Jan 11, 2023

@ljharb @speicus If we were to use the arrow functions constraint, would we be left with creating "traditional" functions inside the component?

function Hello() {
  function handleClick() {
    console.log('Hi!')
  }

  return <button onClick={handleClick}>Hello</button>
}

instead of this?

function Hello() {
  const handleClick = () => {
    console.log('Hi!')
  }

  return <button onClick={handleClick}>Hello</button>
}
function Hello() {
  return <button onClick={() => console.log('Hi!')}>Hello</button>
}

In summary... Can we understand that today, based on all the background we have, it is 0% recommended to use arrow functions?

background:

  • Do not use arrow functions to create a component.
  • Do not use arrow functions to send props to components.
    ...

@ljharb
Copy link
Collaborator

ljharb commented Jan 11, 2023

There's no defense for using arrow functions to create component, but there's plenty of times where sending one as a prop is "fine".

The hazard is passing an inline arrow function as a prop to a custom component, not an HTML one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
@ljharb @speicus @vicasas and others