Arrow Functions, constructor bind and non bind functions with react.js
Arrow Function vs Constructor Bind vs Normal Function
Before I start, wanted to clarify that I understand there are lots of articles and blogs written on the difference between the inline arrow function, auto bind and explicit bind.
Here is mention of those,
https://flexport.engineering/ending-the-debate-on-inline-functions-in-react-8c03fabd144
An article which talks about react, inline arrow function and performance. https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578
Here is another good mention of what I try to highlight in my below post, i.e. about arrow function vs constructor bind vs normal function.
I prefer the following and suggest below to my team,
1) Use functions/method (no bind) and pass attributes to it rather than using “this”. This is the fastest with no contention.
2) Try to bind in the constructor like “this. add = this.add.bind(this)” . In most use cases & this has worked better than arrow functions in major browsers.
(Note https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578 has a good mention of a use case, where binding in constructor always may impact performance in certain cases.)
3) Use class level arrow function for eg: var add = ()=>{….}
or use @autobind
Note: Above is not part of ES2016 and it may not be in ES2017. It may be in ES2018, but as we use Babel to transpile, it was ok to use this.
4) Use the inline arrow function for components that needs it or in case the third option is not possible.
Now the question is, “whether preferring another way than inline arrow function in render a premature performance optimization”, here is my perspective on this quote. I also detail it in another post.
As an architect, designer and coder in both front-end and back-end technologies (react.js, javascript and java/jee), I see them as coding guidelines or standards to keep in mind for any developer to code than premature performance optimization. I advise my team to code with performance, security, logging & auditing in mind.
I see code optimization as first writing the code and then optimizing it. Adding these as coding guidelines will result in writing better code from the start. This way we only have to deal with less code to optimize later as guidelines take care of other cases.
For example, in java, it is preferred to use “StringBuilder” instead of “StringBuffer” especially within a method or in a single-threaded application, although both do the same. I consider them as good coding practices to know, then calling it premature optimization.
Here is a simple code to measure scenarios on the arrow, constructor bind, and normal functions.
You may try out to get a perspective of performance in different browsers.
My experience was as below,
In all browsers, normal functions without bind are executed much faster than the other two.
In Chrome 68.0.3440.106 , constructor bind executed marginally faster than an arrow function.
In Microsoft Edge 38.14393.2068.0, constructor bind executed significantly faster than arrow function.
In Firefox 61.x 64 bit, arrow function executed faster than constructor bind function.
The test was performed in Windows 10 64 bit OS.
Chrome executed faster among the 3 browsers, but again it depends on the javascript engine and browser version.
Clap
Also published on Medium.