Arrow Functions

[00:00:00]
>> Kyle Simpson: Some of you may be wondering, well what about arrow functions? That favorite feature that we've added to ES6 for who knows how long, I mean who knows how long people have been asking for this arrow function, but it finally landed in ES6. I like to imagine that maybe Brendan Ike wanted to do that in the original prototypes, and it just took him 15 years or whatever.

[00:00:23]
But arrow functions arrived in year six a few years back. And it is as if the clouds opened and heaven shone down upon us, if you will, that people just seemed to move to this new level of enlightenment and love and joy for the language once they got the arrow function.

[00:00:41]
You see here on line 1, the usage of an arrow function in the math, as opposed to a name function expression. So you're wondering, hey Kyle, what's your feeling about arrow functions? And my response is, arrow functions are anonymous.
>> Kyle Simpson: I don't think you should use anonymous function expressions, I think you can do the math.

[00:01:01]
I don't think you ought to be using arrow functions. Certainly I don't think you should be using arrow functions as a general replacement for all other functions. You shouldn't be using them just because they're nice and short, concise syntax. That isn't why they were created, that's only one of the characteristics that maybe I think could be argued not even the primary characteristic.

[00:01:22]
The shorter the syntax by the way, the more complex the corner cases of syntax are. And if you've ever wrangled various different corner cases, there is like 15 different variations on the arrow function syntax. So doesn't come without a cost. But I would tell you that the only way looking at line 1 that you can figure out what that error function is doing, is to read it's function body.

[00:01:47]
But when I read the function name I don't need to read any code. There's one English name there that tells me the purpose of that function. A lot of people argue with me and say, the arrow function on line 1 is completely self obvious. Maybe it is self obvious, but it is still an inference.

[00:02:05]
You are still having to infer the purpose of that from the code, rather than seeing the purpose listed out. And if I gave an even better name, I was saving space on the slides. But if I gave an even better name like get person ID or get default person id.

[00:02:20]
I can put lots of more information in there that semantically tells the reader of my code what its purpose is, that would not be obvious in the code.
>> Kyle Simpson: So, my take is, don't use arrow functions for this purpose. Later in the course we will come back to arrow functions and you'll see the one and only one exception that I have to the arrow functions rule, which is their lexical this behavior.

[00:02:44]
But I do not endorse or recommend or suggest using them as a general replacement for any function.
>> Kyle Simpson: Short or long? Another example, if you've done promise chains, I'm not a big fan of promise chains anyway, but if you like to do promise chains, this is another case where you often will just parse in these functions.

[00:03:06]
Here's one of these places where even though, that I was asked earlier, I might tend for my rule because this is a one liner on line 14. I might tend to do that as an inline function expression, because I really dislike the readability of promise chain so much.

[00:03:22]
I find them very hard to read and very spaghetti-ish, very much like the jQuery code that everybody said we shouldn't be doing several years back. I find promise chains to be in that same style. And I used to be in love with that style, and now I very much dislike that style, from a readability perspective primarily.

[00:03:40]
So even though I might normally have a rule where I would pass it as an inline function expression. In this particular case, I would probably pull that function out as a function declaration, and therefore the promise chain would have something like you see on line 11, which is referencing a function by name, instead of a function expression at all.

[00:03:59]
But I still wouldn't use the arrow function like you see on line 10.
>> Kyle Simpson: Now, some people have said, well, they're anonymous, but you can still assign them to variables and get almost the same benefit out of them, right? I can take this getId and assign it a variable called getId, and then I'm using people.map.

[00:04:21]
And it's true that the line 2 definitely does have a name in it called getId. But if you went to the trouble to do line 1, guess what, it's actually fewer characters to do the function declaration. Why do you go to all the trouble especially by the way if you use a const, it's two more characters long.

[00:04:40]
If you do the math, you're actually spending as much or more characters to define the function that way, rather than doing it as a function declaration. So I just don't see any reason why people are stuck on this,other than almost an emotional attachment to this idea that we can write more concise code.

[00:04:59]
Guess what, more concise code does not automatically equal more readable code. In some cases, it does, but in many other cases, it doesn't.
>> Kyle Simpson: So there's my really super unpopular opinion on arrow functions, just some food for thought.