ES6: The Right Parts The Arrow Function

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Kyle Simpson: I'm gonna take you through a tour of the stuff that I think you should pay attention to. But, [COUGH] by popular demand I have to start by going into a feature that I really don't think you should pay attention to. I wouldn't really call this a right part, in the sense of this is the place to start.

[00:00:24] It's not objectively all bad, there's not the zero value to it. But it's the place where everybody's journey with the ES6 seems to start, so I'd be remiss if I didn't start your journey with the arrow function. Now I want to talk about the arrow function and I'm going to give you my opinions because this is all about an opinionated guy.

[00:00:45] I want you to make your own decisions, but I want you to make those decisions in an informed way. That really undergirds everything that I do as a teacher. I want you to make those decisions in an informed way. And, I think, a lot of times, people sort of just follow whatever the hype bandwagon is.

[00:01:01] If every blog post out there is using an arrow function, we assume we're all supposed to use arrow function. So I wanna talk to you about what the arrow function is, some of the problems with it, some of the reasons why it might actually be a valid thing, why it exists and where it might be useful.

[00:01:16] And we're actually gonna get an exercise to practice with it. And I'm gonna go ahead and predict that most, if not all of you, are probably not going to be able to complete it. Because it turns out arrow functions are actually a bit more complex than we've been admitting to ourselves.

[00:01:33] I accidentally created a scenario where, myself, I failed it the first two times I wrote it. So we'll go into that, and we'll see the pros and cons in the places where an arrow function ought to be useful. So what are we talking about? We're talking about this symbol specifically, the fat arrow.

[00:01:51] It's supposed to replace that old and busted function keyword, right? Because function, what is that, eight characters? That's just so many characters to type. Let's type two characters that in the US English keyboard require also the shift key to express so actually. How many characters, how many keystrokes are we really saving?

[00:02:11] But we don't want to write the word function, and we also don't want to write the word foo, because who wants to name their functions? Naming sucks and we also don't want to write the word return, cuz that sucks. We just want to write a nice simple arrow.

[00:02:26] So the equivalent is to have this arrow function and it's an expression, so it can't stand alone like a function declaration it's gotta get assigned to something. So if we had a variable called foo we could assign it. Now this open close parenthesis here, that's the parameter list.

[00:02:45] And when there is one and only one parameter like, for example, if it was x, then you get to just put that there. Without parentheses, great, we get to get rid of our parentheses. You'll notice I didn't have to put any curly braces I didn't have to put a return keyword.

[00:02:58] And if you're really super hipster, you could have even left off the semicolon gone semicolonless. Man, you're just saving characters all over the place. So this is what everybody gets excited about with ES6 is, we get these nice short concise syntactic forms. So is the hype well deserved?

[00:03:20] Now I want to talk to you about some variations on the arrow function syntax. But before I even go into the details about the variations on it, the fact that there are variations is kind of the problem. Because there is virtually no variation in syntax for the standard function.

[00:03:39] The standard function shows up with the function keyword, a name, some parentheses set, a curly brace, generally a return keyword. Almost no variation, whatsoever, syntactically speaking. Meaning everywhere that you use that form, there is already a built in familiarity. Everybody that reads your code, looks at a function and knows exactly what a function does.

[00:04:04] Knows where the curly brace scoping block starts and ends. You start introducing a new form, and you do need to ask yourself when you're trying to make an apples to apples comparison. You need to include that question of, is somebody going to be able to read and, at first glance, still be able to understand this?

[00:04:22] And, also, by the way, ask your developers, ask your developer self, am I gonna be able to write that? I saw a tweet recently from one of the most vocal proponents of the arrow function. He was an early adopter and he's been writing all of his blog posts using the arrow function.

[00:04:39] And he tweeted out, this was a few months ago, he tweeted out he said you know I love arrow functions. But my instinct, I can still write the word function faster than I can write the arrow symbol. After years of writing the arrow function, he still sort of sways back to, it's a little bit easier to just quickly write the function key word.

[00:04:59] And so he writes that then he goes back and he factors into the arrows or something like that. So maybe it's not quite so objectively, amazingly more readable. Maybe there are some caveats to the readability of the function. The fact that there's a lot of variance in syntax means that the reader of your code, having not already been super familiar with this.

[00:05:21] And, by the way, there just aren't that many JavaScript developers that are super familiar with the arrow function. Having not already been familiar with it, it could create a visual stumbling block. Where the person starts to parse and they realize, crap, this is a function. They have to go back and sort of visually reparse it and think why did it need parentheses here?

[00:05:39] And is this returning, is it a curly brace, do I need a parenthesis set here.