DEV Community

ES6 Arrow Functions Cheatsheet

Samantha Ming on February 11, 2019

Here’s a cheatsheet to show you the many ways to write your arrow functions. // Explicit Return, Multi-Line a => { return a } // Explic...

Read full post

Shayne Darren • Feb 11 '19

While I love the arrow function syntax of ES6, I feel like the implicit returns could be a bit problematic. I personally feel in large projects we need to enforce the use of body braces and explicit returns, as that is the only syntax that will work consistently, regardless of the changes made to the function(adding a parameter, changing the return type, adding 1 more line).

However, implicit returns and concise block are pretty useful in keeping the code concise with minimum boilerplate when you're chaining several methods together.

What are your thoughts on this? Have you encountered these issues?

Guillaume Martigny • Feb 11 '19

Like a lots of things in JS, you can screw yourself if you're not careful with the flexible syntaxe.

ESlint (with airBnB rules) can help a lot with this. As you said, there's two (maybe three) ways to use arrow-functions. Here's the two syntaxes I enforce to myself.

1 Simple one-liner:

this.children.forEach(child => child.remove()); // Without implicit return
const translated = points.map(point => point.add(x, y)); // With implicit return

1.1 Object return:

const options = values.map(value => ({
  value: value,
  size: value.length,
}));

2 Multi-line operation:

object.data.forEach((data) => {
  test(data.value);
  test(data.size);
});

Mihail Malo • Feb 12 '19

I feel like all optional symbols must be eradicated.
I'm just on the fence with returning someone else's undefined or even worse another return when you don't want a return.

as.forEach(x => map.set(a.name,a.value)) // Oh no, I am returning the map instance!
as.forEach(x => console.log(x)) // Oh no, I am returning `console.log`'s `undefined`

For the longest time, I would avoid that, adding a {}, especially if this is an otherwise available function.

const addToMap = x => { map.set(a.name,a.value) }
const log = x => { console.log(x) }

as.forEach(addToMap) // Ahh, bliss
as.forEach(log)

But then, on one cursed day, I once again stumbled upon ES6 tail call optimization spec. (Unlike most ES6, it is implemented ONLY in Safari & Mobile Safari, was REMOVED from Chrome, and is not in active development anywhere else.)

So, what is a tail call for that spec? Why, it's a function call the result of which is then returned, unconditionally. So you see my problem.
I have never had a night of good sleep since, and I am sure you can relate, since it would mean that functions like

const addToMap = x => map.set(a.name,a.value)
const log = x => console.log(x)

With the return value discarded as late as possible, are superior.

JavaScript Joel • Feb 12 '19

I personally feel in large projects we need to enforce the use of body braces and explicit returns, as that is the only syntax that will work consistently, regardless of the changes made to the function(adding a parameter, changing the return type, adding 1 more line).

I'm curious about your reasoning here and if you have any examples that could clear things up for me.

I don't see the syntax as being retired to project size.

Changing either the input or output of a function should be the same in both situations.

Islam Sayed • Feb 11 '19

Concise article like the concise body of arrow function. Thank you.

Samantha Ming • Feb 25 '19

No problem, glad you found it helpful!

Mihail Malo • Feb 12 '19

(a, b) => a, b

Oh god, what is that :v

Samantha Ming • Feb 18 '19 • Edited

I just want to show the parameters being used. But I can see how this is confusing. One shouldn't return with a , for sure. But for those wondering why, see below for the output of this function:

const someFunc = (a, b) => {
  return a, b
}

someFunc('a', 'b'); // 'b'
// It returns only the last argument

Mihail Malo • Feb 18 '19 • Edited

No, the real WUT is this:

let fn = (a, b) => a, b
fn('a','b') // It won't be 'b' :)

fn = (a, b) => (a, b)
fn('a','b') // Now it will.

// Honorable mention:
fn = ((a, b) => a, b)
fn('a','b') // Uncaught TypeError: fn is not a function
// (It's actually the `undefined` `b` declared at line 1:23)
// How excellent is that?!

Jesse M. Holmes • Mar 26 '19

I've had to consider which of these I like:

// plural/singular relationships
this.children.forEach(child => child.name = 'George');
// initials, picked up from Linq usage
this.children.forEach(c => c.name = 'George');

Samantha Ming • Mar 27 '19

I personally prefer the plural/singular because it’s more descriptive. It might not be as obvious because your example is only a one-liner. But once you have more logic inside the loop, it’s helpful for others to follow along your code and even yourself down the road. It takes removes the guessing 😊

Camilo Martinez • Feb 13 '19

And what about arrow functions with zero parameters?

Samantha Ming • Feb 18 '19 • Edited

That should definitely be in the notes!

// zero parameters require parentheses
() => "👍"

Adrián Norte • Feb 12 '19

I'm a simple man, I see arrow functions I click love. :P

Samantha Ming • Feb 18 '19

Arrow functions FTW 😆🙌

Habel Justin • Feb 11 '19

thanks for this

Samantha Ming • Feb 18 '19

You're welcome! Glad you found it helpful 👍

slumboy • Feb 12 '19

Wowww.. I see you in Twitter and here again. ^{__^}

Samantha Ming • Feb 18 '19

Yup! I post my code notes here and on medium 😄

Edu Souza • Oct 3 '20

what wonderful content!