Applications of ES6 Arrow Functions in React

Arrow functions arrived as a promising solution to make “this” easy to handle.

An arrow function is a function with the following qualities:

1. this, arguments, super, new.target, keywords inside an arrow function are lexically bound to the parent scope and not the runtime invocation context. Having said that since you cannot change “this” after definition, one cannot use bind(Function.bind) to change it to some other context.
2. Arrow functions are always anonymous. One cannot refer to them directly like a function declaration. You have to assign it to a variable or as a property.

To use arrow functions in older browsers which don’t support ES6, transpilers(ES6+ to ES5 code) are used and Babel is the most popular of them.

Babel transpiles arrow functions defined in a function scope, using a _this variable to store the this(parent scope’s invocation context) and replaces this mentioned at all places inside the function definition with _this. Even if function is bound to a different context using Function.bind, _this is not influenced, it just works. There is one gotcha with this transpilation approach, when an arrow function is defined in the global scope, function should have this pointing to the window object since the parent scope is the global scope, but instead it transpiles this to undefined as shown below.

I tried to reason this behaviour with “This approach is not possible to implement in global scope because the _this will override/be_overriden_by value of any user defined global variable _this”. This is edge case doesn’t impact much as global scoped arrow functions have no real application.

Its good to be aware how babel transpilation works and if its behaving according to the standard in all situations. Avoid code that behaves differently when transpiled and in browsers that support ES6. You don’t want to have any migration headaches when you remove babel. 
Refer ES Compat Table to know if you have an opportunity to check which browsers support a feature, then check if babel behaves the same way.

As perfectly described in a strongloop(creator of express.js)’s blog post.

I recommend using arrow functions only in places where you explicitly want to use the new features:

• Single statement functions that immediately return (lambdas)
• Functions that need to work with parent scope this

So where can you use them

1. Single statement functions that immediately return (lambdas): 
   - callbacks of promises, Array.map, …you name it.
2. Functions that need to work with parent scope this:
   - setTimeout, Array.map where this is different from parent scope.
   - super can be used in instance methods defined inside constructor function by using arrow functions as super keyword is lexically bound to its parent scope (here it’s the constructor function). normally you would assign super to a placeholder variable like self, that etc.

• A single line solution in order to pass arguments beforehand is Function.bind, but it brings side-effects due to its defined behaviour
• bind requires an invocation context to which it is bound to. So we are passing this even if don’t want to change it.
• passed arguments are prepended to arguments provided to the bound function when invoking the target function, so we have no control over the order of arguments.
• the callback doesnt make it clear whether the event object is used or not?

“e” is passed as first argument and its clear

2. Binding user-defined method’s this to component:

Refer https://babeljs.io/blog/2015/06/07/react-on-es6-plus#arrow-functions to know how ES7 property initializers + Arrow functions are used to bind this to the component inside a user defined method.

When using arrow function syntax, the order in which the methods are declared matters as shown below.

To prevent these problems its a good practice to define different entities in a component in the following order:

1. user defined methods and properties
2. state(getInitalProps),
3. static props(getInitialprops),
4. lifecycle methods

The execution of a component doesn’t start with (1). So by keeping them at the top, the properties (2), (3), (4) are trying to access are above them making sure they are defined.

3. Namespacing methods in a component class definition

• As the number of user defined methods increase in a component, they become unmaintainable and hard in finding a particular method within the list.
• In normal javascript we deal long list of functions by namespace-ing. But its not straightforward to achieve it in the ES6 classes and keep their “this” bound to the component.
• A usual way is to write the methods in the normal way and bind them to this in the componentWillMount method but here the function definition and “this” binding is done at different places, its straight-forward for someone unfamiliar with the codebase to know if the binding exists.
• Using ES7 property initializers + Arrow functions
  - this is binded to the component and its not a hidden fact.
  - the boilerplate is limited to creating the namespace, where as in bind you have to bind each of the methods declared.

References:

1. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions
2. https://strongloop.com/strongblog/an-introduction-to-javascript-es6-arrow-functions/
3. http://www.2ality.com/2016/02/arrow-functions-vs-bind.html
4. https://babeljs.io/blog/2015/06/07/react-on-es6-plus#arrow-functions
5. https://facebook.github.io/react/docs/reusable-components.html#no-autobinding

Please let me know if have any points for/against the approaches suggested. Feel free to comment.