{"id":32,"date":"2018-09-07T06:52:31","date_gmt":"2018-09-07T06:52:31","guid":{"rendered":"http:\/\/www.webagam.com\/?p=32"},"modified":"2020-12-11T23:19:34","modified_gmt":"2020-12-11T23:19:34","slug":"arrow-functions-constructor-bind-and-non-bind-functions-with-react-js","status":"publish","type":"post","link":"https:\/\/webagam.com\/pages\/2018\/09\/07\/arrow-functions-constructor-bind-and-non-bind-functions-with-react-js\/","title":{"rendered":"Arrow Functions, constructor bind and non bind functions with react.js"},"content":{"rendered":"
2<\/div> \r\n\t\t\t\t\t\t\t\t\t
\r\n\t\t\t\t\t\t\t\t\tClap\r\n\t\t\t\t\t\t\t\t\t<\/span>\r\n\t\t\t\t\t\t\t\t\t<\/div><\/div><\/div>

Arrow Function vs Constructor Bind vs Normal Function<\/strong><\/p>\n

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.
\nHere is mention of those,<\/p>\n

https:\/\/flexport.engineering\/ending-the-debate-on-inline-functions-in-react-8c03fabd144<\/a><\/p>\n

An article which talks about react, inline arrow function and performance. https:\/\/cdb.reacttraining.com\/react-inline-functions-and-performance-bdff784f5578<\/a><\/p>\n

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.<\/p>\n

https:\/\/medium.com\/@charpeni\/arrow-functions-in-class-properties-might-not-be-as-great-as-we-think-3b3551c440b1<\/a><\/p>\n

I prefer the following and suggest below to my team,<\/p>\n

1)\u00a0\u00a0\u00a0\u00a0\u00a0 Use functions\/method (no bind) and pass attributes to it rather than using \u201cthis\u201d. This is the fastest with no contention.<\/p>\n

2)\u00a0\u00a0\u00a0\u00a0\u00a0Try to bind in the constructor like \u201cthis. add = this.add.bind(this)\u201d . In most use cases & this has worked better than arrow functions in major browsers.<\/p>\n

(Note https:\/\/cdb.reacttraining.com\/react-inline-functions-and-performance-bdff784f5578<\/a> has a good mention of a use case, where binding in constructor always may impact performance in certain cases.)<\/p>\n

3)\u00a0\u00a0\u00a0\u00a0\u00a0 Use class level arrow function for eg: var add = ()=>{\u2026.}<\/p>\n

or use @autobind<\/p>\n

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.<\/p>\n

4) Use the inline arrow function for components that needs it or in case the third option is not possible.<\/p>\n

Now the question is, \u201cwhether preferring another way than inline arrow function in render a premature performance optimization\u201d, here is my perspective on this quote. I also detail it in another post.<\/p>\n

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.<\/p>\n

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.<\/p>\n

For example, in java, it is preferred to use \u201cStringBuilder\u201d instead of \u201cStringBuffer\u201d 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.<\/p>\n

Here is a simple code to measure scenarios on the arrow, constructor bind, and normal functions.<\/p>\n