DEV Community

Arrow functions: a walkthrough and gotchas

Sylwia Vargas on July 08, 2020

In this blog post I show how to transform a traditional function into a so-called 'arrow function'. I start with functions with two arguments, then...

Read full post

Reed Jones • Jul 9 '20

const helloWorld = _ => console.log("Hi") doesn't really mean 'there will be for sure no defaults', in fact it can be used as a regular variable!

const double = _ => _ * 2 double(5) // 10

its really no different than

const double = number => number * 2

Sylwia Vargas • Jul 9 '20

Yeah, it can be used as a variable but customarily, it seems to mean that there wouldn't be any default arguments. Codewise, it is not different - you are right in that.

Kyle Roach • Jul 10 '20

Customarily? Actually, if you use any linters like eslint or typescript, using _ will tell the developers that it does have an argument, while () shows as void and passing any argument will throw a warning.

See typescriptlang.org/play/index.html...

Sylwia Vargas • Jul 10 '20

I wouldn't say TypeScript is a linter — did you mean TSLint?
I appreciate you bringing TS perspective but the blog post is entirely about just JS.

Historically, as linters are considered, the underscore parameters would trigger is declared but never used error, which was fixed in TypeScript 2.0. However, it does still trigger unused variable/parameter warning from a linter. As we all know, linters are not always correct or up to date.

As I said, it is a niche thing and I trust my colleagues who expressed such an opinion. Perhaps it is also a team-depending styling choice.

I heard that the difference is that if e.g. you run in the browser console now and paste

document.body.addEventListener("click", () => console.log(event))

this will still have an access to the default argument that's event, which would not be the case with _. However, trying this out with _ that works as well so maybe that's browser-dependent? In all honesty, I don't have the time now to track this down but will put it in the "parking lot" for the times when I can research it.

Also, it's fascinating that you've been on Dev for over two years and this is your first post or comment ever. I'm quite happy that my post evoked such strong feelings that you decided to respond!

Kyle Roach • Jul 10 '20 • Edited

Sure, TypeScript isn't exactly a linter and this post isn't about TypeScript, but I would say that today a lot of js tooling is powered by typescript so it's not a far stretch.

But okay let's use JSDoc, which isn't typescript related. You can see it still generates _ to be expecting a variable.

Sylwia Vargas • Jul 10 '20

I'm happy you feel passionate about this subject and I appreciate the time you put into this (making the screen recording, converting it into a gif, uploading it). For now, I'll just repeat: "As we all know, linters are not always correct or up to date." I'd be curious what docs say about it if you wanted to actually check what the motivation/history is behind introducing the _ as a variable.

Kyle Roach • Jul 10 '20

_ as a variable is used when you want to ignore the first parameter when using a function, we sometimes call it a throwaway variable.

A great example in the Array.forEach method. Say we wanted to loop through items in an array and console out the index.

The first argument in the forEach callback is the item, and the second is the index. Because parameters are ordered in js, if we want to use the 2nd one, we have to provide a variable for the 1st one.

const names = ['Sylwia', 'Kyle']; names.forEach((name, index) => console.log(index))

Since what we really need is the second variable, we can omit the first one with _.

names.forEach((_, index) => console.log(index))

So _ acknowledges there is a parameter there, but we're not using it in our implementation.

Here are two posts I found you can use for reading:

stackoverflow.com/questions/276370...
The section on "No Arguments with Arrow Functions" wesbos.com/arrow-functions

Sylwia Vargas • Jul 10 '20 • Edited

Awesome! Thanks. This is what I meant by

there will for sure be no defaults you care about

I was aware of the Wes Bos' post, which is where I encountered the _ back in the day. Since this is niche, produces warnings and seems to be treated differently by dev teams, I am quite curious about how the argument came to be and what the intention was behind it — perhaps the ES6 standards or discussion thread will shed some more answer.

Thanks for the research — I've included a mention of your comment in the blog :)

𒎏Wii 🏳️‍⚧️ • Jul 9 '20

and you need {} as soon as you have more than 1 line of function body

Almost but not completely correct. You need {} when the function body is not just one expression, that is, when you need additional statements before the return value. You can easily write something like

const sum = (array) => array .reduce( (a,b) => a+b);

but you can't do

const sumPlusOne = (a, b) => a+=1; a+b

Sylwia Vargas • Jul 9 '20 • Edited

Good catch! I've edited the post to include your comment and attributed it to you :)

Jérôme Gamez • Jul 9 '20

A nice and concise overview and explanation on how to migrate to arrow functions, thank you!

Sylwia Vargas • Jul 9 '20

Thank you, Jérôme! I appreciate you taking the time to comment not to correct but to show appreciation. I think the world would be a better place if we took more time to give shout outs as a habit :)

Jérôme Gamez • Jul 9 '20

Reading some other comments before posting mine this was exactly what I thought 😅.

Sylwia Vargas • Jul 9 '20

Yeah, we still have a long way to go as a community if any time you write an intro blog post, you'd get a 10x dev feeling personally offended that you didn't include something way more advanced 😂

oh well, thanks for being a wholesome human!

András Tóth • Jul 9 '20 • Edited

I recommend proof-reading the article as you have left in some typos and unfinished sentences:
e.g. NOW RETURN?! and it’s a niche thing and no one uses it even in obscure dev <- this sentence is not finished.

When discussing the arrow functions it is important to mention that it does not have its own this. So you can't bind these types of functions. Personally, I think you should use anonymous functions for small throwaway functions. Whenever you need reusable stuff you should aim to use the real, normal functions.

Also one more thing might have been mentioned and that is returning an object without the return keyword:

myArray. map(item => ({ prop1: item.prop1 + item.prop2, prop2: item.prop3 }) );

Or even adding destructuring to the mix:

myArray. map(({ prop1, prop2 }) => ({ anotherProp1: prop1, prop2, }) );

Sylwia Vargas • Jul 9 '20 • Edited

Hi Andras! Thank you for taking the time to write this. I initially planned to talk about this, hoisting and function expressions, execution context, etc. but realized that:

this blog post is a beginning of a series called "js warm-ups" and is meant as supplement to helping people understand basic js concepts in a simple way;
the blog post was getting long and therefore, potentially overwhelming for people trying to just understand what the hell arrow functions are.

I decided to split it into two (or more), this one addressing the direct need of some of my students (expressed yesterday) and the other will be published when I have time to finish it later this week. Sadly, I entitled the blog before I finished it. Just bear with me :)

I did edit the post to include the two main gotchas, though.

András Tóth • Jul 10 '20

You are right, for beginners it must be scary. That's I think an inherent problem with the learning curve of JS: first it's very flat, then there's a huge uphill mountain to grasp all the quirks and gotchas (around function pointers, this and objects, immutability of Promises) and then it's very flat again.