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:
this.children.forEach(child=>child.remove());// Without implicit returnconsttranslated=points.map(point=>point.add(x,y));// With implicit return
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
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.
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.
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
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'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.
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.