Here’s a cheatsheet to show you the many ways to write your arrow functions.
// Explicit Return, Multi-Line
a => {
return a
}
// Explicit Return, Single-Line
a => { return a }
// Implicit Return, Multi-line
a => (
a
)
// Implicit Return, Single-Line
a => a
// Multiple Parameters, Parentheses Required
(a, b) => a, b
Implicit vs Explicit Return
We have several ways of writing our arrow functions. This is because arrow functions can have either "implied return" or "explicit return" keyword.
With normal functions, if you want to return something, you have to use the return
keyword. Arrow functions also have that. When you use the return
keyword, it's called an explicit return. However, arrow functions up their game and allow something called implied return where the return
keyword can be skipped. Let's look at some examples 🤓.
Example A: Normal Function
const sayHi = function(name) {
return name
}
Example B: Arrow Function with Explicit Return
// Multi-line
const sayHi = (name) => {
return name
}
// Single-line
const sayHi = (name) => { return name }
Example C: Arrow Function with Implicit Return
// Single-line
const sayHi = (name) => name
// Multi-line
const sayHi = (name) => (
name
)
Notice the difference? When you use curly braces {}
, you need to explicitly state the return. However, when you don't use curly braces, the return
is implied and you don't need it.
There's actually a name for this. When you use curly braces like in Example b, it's called a block body. And the syntax in Example c is called a concise body.
⭐️ Here are the rules:
- Block body ➡️
return
keyword is required - Concise body ➡️
return
keyword is implied and not needed
Parentheses
With a normal function, we always had to use parentheses. However, with Arrow Functions, parentheses are optional if there is ONLY one parameter.
Parentheses are optional for a SINGLE parameter
// Normal Function
const numbers = function(one) {}
// Arrow Function, with parentheses
const numbers = (one) => {}
// Arrow Function, without parentheses
const numbers = one => {}
Parentheses are required for MULTIPLE parameters
// Normal Function
const numbers = function(one, two) {}
// Arrow Function, with parentheses
const numbers = (one, two) => {}
⚠️ Arrow Functions Gotcha: Returning Objects
Remember I mentioned about the different body types - concise body and block body. Just to quickly update you in case you skipped that section (I'm a bit sad, but not offended 😝). Block body is where you use curly braces and have an explicit return
. Concise body is where you don't use curly braces, and you skip the return
keyword. Alright, now you're caught up, let's get back to the gotcha 🤯
Let's purposely break our code, so you can learn your lesson lol 😂
const me = () => { name: "samantha" };
me(); // undefined 😱
What?! Why isn't it returning my object. Don't worry, let's fix it by wrapping it in parentheses.
const me = () => ({ name: "samantha" });
me(); // { name: "samantha" } ✅
⭐️ Here's the rule:
- For a concise body, wrap object literal in parentheses
Resources
Thanks for reading ❤
Say Hello! Instagram | Twitter | Facebook | Medium | Blog
Top comments (20)
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?
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:
1.1 Object return:
2 Multi-line operation:
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.For the longest time, I would avoid that, adding a
{}
, especially if this is an otherwise available function.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
With the return value discarded as late as possible, are superior.
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.
Concise article like the concise body of arrow function. Thank you.
No problem, glad you found it helpful!
Oh god, what is that :v
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:No, the real WUT is this:
I've had to consider which of these I like:
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 😊
And what about arrow functions with zero parameters?
That should definitely be in the notes!
I'm a simple man, I see arrow functions I click love. :P
Arrow functions FTW 😆🙌
thanks for this
You're welcome! Glad you found it helpful 👍
Wowww.. I see you in Twitter and here again. __^
Yup! I post my code notes here and on medium 😄
what wonderful content!