What scenarios are not suitable for JS arrow functions?

Overview

After all these years, ES6 has taken js usability to a new level: arrow functions, classes, etc., which are great.

Arrow functions are one of the most valuable new features, and there are many good articles describing their context transparency and short syntax.

But every transaction has two sides. Often, new features bring some confusion, and one of those confusions is the misguided use of arrow functions. This article will cover some scenarios where you should bypass arrow functions in favor of good old function expressions or the newer shorthand syntax. Also be careful to shorten your code as this will affect the readability of the code.

Defining methods on an object

In JavaScript, methods are functions stored as properties of an object. When the method is called, this will refer to the object to which the method belongs.

Object literals

Since arrow functions have a short syntax, it's tempting to use them to define methods. Let's give it a try:

const calculate = {
  array: [1, 2, 3],
  sum: () => {
    console.log(this === window); // => true
    return this.array.reduce((result, item) => result + item);
  }
};
console.log(this === window); // => true
// Throws "TypeError: Cannot read property 'reduce' of undefined"
calculate.sum();

The calculate.sum method is defined using an arrow function. But when called, calculate.sum() throws a TypeError because this.array is undefined.

When the sum() method is called on the calculate object, the context is still window. This happens because the arrow function lexically binds the context to the window object.

Executing this.array is equivalent to window.array, which is undefined.

The solution is to use a regular function expression to define the method. this is determined at call time, not by the enclosing context. Let’s take a look at the fixed version:

const calculate = {  
  array: [1, 2, 3],
  sum() {
    console.log(this === calculate); // => true
    return this.array.reduce((result, item) => result + item);
  }
};
calculate.sum(); // => 6

Because sum is a regular function, when you call calculate.sum(), this is the calculate object. this.array is an array reference, so the sum of the elements is calculated correctly: 6.

Object prototype

The same rules apply to defining methods on prototype objects. Use an arrow function to define the sayCatName method, this points to window

function MyCat(name) {
  this.catName = name;
}
MyCat.prototype.sayCatName = () => {
  console.log(this === window); // => true
  return this.catName;
};
const cat = new MyCat('Mew');
cat.sayCatName(); // => undefined

Using the earlier way to define a function expression:

function MyCat(name) {
  this.catName = name;
}
MyCat.prototype.sayCatName = function() {
  console.log(this === cat); // => true
  return this.catName;
};
const cat = new MyCat('Mew');
cat.sayCatName(); // => 'Mew'

The sayCatName regular function changes the context to the cat object when called as a method: cat.sayCatName().

Dynamic context callback function

this is a powerful feature in JS that allows the context to change depending on how a function is called. Typically, the context is the target object where the call happens, which makes the code more natural, as if what happens to this object.

However, arrow functions statically bind the context on the declaration and cannot be made dynamic, but this approach has both good and bad sides, and sometimes we need dynamic binding.

Attaching event listeners to DOM elements is a common task in client-side programming. The event triggers the handler function and uses this as the target element. Using an arrow function here is not flexible enough.

The following example attempts to use an arrow function for such a handler:

const button = document.getElementById('myButton');
button.addEventListener('click', () => {
  console.log(this === window); // => true
  this.innerhtml = 'Clicked button';
});

In the global context this refers to window. When a click event occurs, the browser tries to call the handler function using the button context, but the arrow function does not change its predefined context. this.innerhtml is equivalent to window.innerHTML and has no meaning.

A function expression must be applied, which allows changing this depending on the target element:

const button = document.getElementById('myButton');
button.addEventListener('click', function() {
  console.log(this === button); // => true
  this.innerHTML = 'Clicked button';
});

When the user clicks the button, this in the handler function points to button. Hence this question. innerHTML = 'Clicked button' correctly modifies the button text to reflect the clicked state.

Calling the Constructor

this in a constructor call is the newly created object. When new MyFunction() is executed, the context of the constructor MyFunction is a new object: this instanceof MyFunction === true.

Note that arrow functions cannot be used as constructors. JavaScript implicitly prevents this by throwing an exception.

Regardless, this is set from the enclosing context, not the newly created object. In other words, the arrow function constructor call does not make sense and is ambiguous.

Let's see what happens if we try to do this:

const Message = (text) => {
  this.text = text;
};
// Throws "TypeError: Message is not a constructor"
const helloMessage = new Message('Hello World!');

When executing new Message('Hello World!') where Message is an arrow function, JavaScript throws a TypeError error because Message cannot be used as a constructor.

The example above can be fixed using a function expression, which is the correct way to create a constructor (including a function declaration):

const Message = function(text) {
  this.text = text;
};
const helloMessage = new Message('Hello World!');

Shorthand syntax

Arrow functions have a nice property that they can omit parameter parentheses (), block braces {}, and return if the function body has only one statement. This helps in writing very short functions.

The original author's university programming professor gave students an interesting task: write the shortest function to calculate the length of a string in C language. This is a great way to learn and explore a new language.

However, in real applications, many developers read the code. The shortest syntax isn't always appropriate to help your colleagues instantly understand what the method does.

At some point, shorthand functions become hard to read, so try not to overuse them. Let me show you an example.

const multiply = (a, b) => b === undefined ? b => a * b : a * b;
const double = multiply(2);
double(3); // => 6
multiply(2, 3); // => 6

multiply returns the result of multiplying two numbers or a closure bound to the first argument for later multiplication operations.

The function works fine and seems short. But it was hard to understand what it did from the beginning.

To make it more readable, you can restore the optional curly braces and return statement from the arrow function, or use a regular function:

function multiply(a, b) {
  if (b === undefined) {
    return function(b) {
      return a * b;
    }
  }
  return a * b;
}
const double = multiply(2);
double(3); // => 6
multiply(2, 3); // => 6

It's good to find a balance between brevity and verbosity that makes the code more intuitive.

Summarize

There is no doubt that arrow functions are a great addition. When used correctly, it makes it easier to use .bind() or try to capture the context in places where you previously had to. It also simplifies the code.

Advantages in some situations can create disadvantages in others. Arrow functions cannot be used when dynamic context is required: defining methods, creating objects using constructors, getting the target from this when handling events.

The above is the details of why JS is not suitable for arrow functions. For more information about JS, please pay attention to other related articles on 123WORDPRESS.COM!