[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.