[Question] Use arrow functions or bind manually in es6 classes? Any performance difference?

[lei-clearsky]

In terms of performance, is there any difference between using arrow functions and bind manually when using es6 classes? Using arrow functions the methods are not on the class prototype, it will be on the class instance only. Using bind will attach the methods to class prototype. It sounds like bind manually will have better performance, does that mean we should consider using bind instead of arrow functions for class methods?

Any suggestions or comments are really appreciated!

So in terms of performance, would you recommend using

class MyComponent extends React.Component {
  constructor(props) {
    super(props)
  }

  methodA = () => { ... }
}

or

class MyComponent extends React.Component {
  constructor(props) {
    super(props)
    this.methodA = this.methodA.bind(this)
  }

  methodA() { ... }
}

[gaearon]

Hi!

These two ways of writing it are equivalent. (The second one is compiled to the first one.)

Using bind will attach the methods to class prototype.

In your example, you still attach the function to the instance:

this.methodA = this.methodA.bind(this)

So they’re essentially the same.

At Facebook, we use the second way (“class properties”) but be aware this is still experimental, and not part of ES6. If you only want to stick with stable syntax, then you could bind them manually.

I hope this helps!

[aweary]

As far as runtime behavior goes they are identical, but doing the later (binding a method in the constructor) means you're defining the method on the class prototype and the instance.

Doing the former will only define the method as an instance property, avoiding the duplication. But as mentioned, it's experimental so YMMV. Check out this example in the Babel REPL to see the difference.

[lei-clearsky]

Thanks @gaearon this is very helpful!

This question was coming from when testing component methods, as I can find the method on class prototype if I use this.methodA = this.methodA.bind(this), but can't find the method on prototype if I use methodA = () => { ... }. See this issue on enzyme: enzymejs/enzyme#365

[lei-clearsky]

@aweary thanks! this helps a lot as we are in the process of converting React.createClass to es6 classes.

[gaearon]

@lei-clearsky

Also check out the automatic class transform:

jscodeshift -t ./transforms/class.js --mixin-module-name=react-addons-pure-render-mixin --flow=true --pure-component=true --remove-runtime-proptypes=false <path>

We used it to convert thousands of components.

It's documented here: https://github.com/reactjs/react-codemod#explanation-of-the-new-es2015-class-transform-with-property-initializers

[lucasconstantino]

I've just read an article which seems to disagree with the conclusions on this issue. Do you guys mind to give an opinion on that? Here it goes:

https://medium.com/@charpeni/arrow-functions-in-class-properties-might-not-be-as-great-as-we-think-3b3551c440b1

[ljharb]

A best practice, imo, is to never use an arrow function in a class property; it harms testability and limits what the engine can optimize.

[creativetim]

re: @lucasconstantino, would love to hear opinions from FB about that article in addition to how they go about testing those kinds of methods or perhaps deciding not to test them.

[TrySound]

@creativetim Component methods are usually implementation detail, so they shouldn't be tested. props/callbacks is the only interface you should use most of the time.

If you use some methods as part of public api, this api should be used only through ref. In this case you should also test those methods only though ref. So bind, arrow or even inlined functions shouldn't care you.

[ljharb]

I don’t agree with that; using refs from outside a component to reach into it is a bad practice.