3 Examples Of When Not To Use Javascript Arrow Functions
Published: 2020-03-21 22:31:46


Photo by Nick Fewings on UnsplashES6 

#Arrow Functions
You know them, you love them, and you probably use them all the time! Introduced as part of the ECMAScript 6 update in 2015, arrow functions exploded in popularity, and with good reason. Arrow function syntax is wonderful syntactic sugar that removed the need for the following:

-the return keyword (for one line functions)
-the function keyword
-curly brackets

Arrow functions also reduced some of the complexity involved in JavaScript function scope as well as the this keyword, because sometimes all you really need is an anonymous function. 

All that being said, arrow functions are not a one size fits all solution for every need you will encounter when writing JavaScript functions. Let's dive into a few situations in which arrow functions are not the right answer.

#Object Methods
Let's say you want to create a method to bind to an object. 

{% gist https://gist.github.com/askoenig/c97c22479a418e0c6a2669a5ea33e3d3 %}

In this example, if we call mario.oneUp() we expect the value of mario.lives to increase from 3 to 4. However, as currently written the value of lives will remain unchanged regardless of how many times oneUp()  is invoked. 

Why is this? The answer is this !

With arrow function syntax, this is inherited from the parent scope, which in this case would be window because an arrow function is always bound lexically with the window object. 

So in this case, invoking oneUp() would be asking your program to increment lives in the window object, which of course does not work.

#Object Prototype
Here's the JavaScript snippet we will be working with for this example:

{% gist https://gist.github.com/askoenig/5cbe9abe440b4febafedf769a175290c %}

Our function invocation on line 15 would out the following: 

true
undefined

We defined the speak() prototype function and passed in a catchphrase for our new Robot object, so why does this code evaluate to undefined?

The console.log() reveals why. As you can see, when we ask the console to evaluate if (this === window), it returns true. This provides proof of what we discussed in the previous Object Methods example.

When working with functions that require context, we must use the regular function syntax in order for this to be properly bound:

{% gist https://gist.github.com/askoenig/3a94997d7ef5a4e9160b8cf0ced6ddd1 %}

#Dynamic Context
Here's our final example:

{% gist https://gist.github.com/askoenig/28a0f0478509015542112c957830e326 %}

By now you're probably aware that this code will not work, as well as why it won't work. I'll give you a hint, it has something to do with this, again.

Arrow function syntax binds context statically upon function declaration, which is the opposite of what we're trying to achieve when working with event handlers or event listeners, which are inherently dynamic.

When manipulating the DOM via event handlers or listeners, triggered events point to the this belonging to the targeted element. 

For an arrow function defined in the global execution context, this will point to window. So in the above code, this.classList will evaluate to window.classList, resulting in a TypeError.

#That's all folks!
I hope these examples were easy to follow and understand. If not, I would recommend reading up on this in JavaScript to help augment your understanding of when to use or not use arrow functions.

As always, thanks for reading!