This course has been updated! We now recommend you take the JavaScript: The Recent Parts course.
Transcript from the "Promises & This" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Kyle Simpson: I get people all the time saying, but I write promises and man I hate doing stuff like this, I hate doing you know, I hate having to write out.
>> Kyle Simpson: I don't want to have to write that. That's way too long. I want to just write p.then.
[00:00:30]
>> Kyle Simpson: That's so much nicer right? In the case where, we make a simple return value. You probably think to yourself. No big deal right? It's much shorter just though in an arrow function. What do you think happens if v comes through is null or undefined? Here's a hint, JavaScript exception is their own because you don't try to do a property access against the null or an undefined value.
[00:01:01] Okay, so this arrow function is going to show up as an anonymous function right there in your stack trace. So even in these cases these real simple cases these little one liner things where you think it's a clear win in readability. The cost comes on the back end whenever something breaks and now you have a worse stack trace to deal with.
[00:01:20] A stack trace that doesn't give you any help to understand what's going on. You have to click through the code to go figure it out. I think you ought to use name functions. And I think you ought to give this some kind of name like extract ID. The reason I think you ought to do that is the extract ID name is going to be used in the stack trace, that will make your code more debuggable, but it also makes this code more sensible.
[00:01:45] I don't have to read the code on line three to figure out what it's returning. Because the name right there at the top tells me what it's doing. It tells me that it's extracting the ID.
>> Kyle Simpson: So the next time somebody makes an unambiguous absolute statement that arrow functions are more readable than name function expressions.
[00:02:05] Just ask yourself how true really is that. This goes for promise.thens, this goes for .mapcalls. I use named function expressions not arrow functions form because I prefer to have the syntax consistency. I prefer to have self reference if I need it. I prefer to have self explaining code with name expressions.
[00:02:28] That's just me. I'm crazy that I like to make my code a little bit more readable.
>> [INAUDIBLE]
>> Kyle Simpson: Okay a few other people maybe.
>> Speaker 2: I always start with the code on the bottom and then eventually like I need to put some logic in there and so I wrap it with parentheses and I'm like yeah well I want to return an object.
[00:02:46] So you know I am renting. I'm just throwing in difference syntax rules as I go develops.
>> Kyle Simpson: My little joke that I tell people about arrow functions if you write an arrow function and it doesn't parse. Just start wrapping parentheses in curly braces around stuff and still it does.
[00:03:05] That's all you know how to do it. I want to pull up. You see here in the shot you see I've got a book series called you don't know JS people who know a lot about those books that I've written the ES6 and beyond was the last book in the series.
[00:03:20] In chapter two of this book I cover arrow functions. And I talk about a lot of these things. Half as a joke and half seriously I've included a flow chart on how to decide whether or not and in what way you're going to want to use arrow functions.
[00:03:39] So let me and why this isn't zoom in question something about the video me a little bit hard to read if you're looking on the projector but you can go find this in the chapter starts off with are you really sure you want to narrow function but then it just keeps going it's like you have exactly one is it a simple parameter without anything.
[00:03:56] Are you returning a value do you not need to return a value as an object value. By the end you get down to this and you have made your decision. Congratulations go forth an arrow function. But take a step back holistically and ask yourself Is this the decision chart you really wanna run through, every time you have to write a function, or how to just write the function keyword?
[00:04:15] Cuz I bet you can run that faster type that faster than you can run through all of these steps. And I bet the readers of your code are going to be able to read it more quickly. So does that mean I'm saying the arrow function is entirely bad and should be just thrown out of the language?
[00:04:32] That's not at all what I mean. There is one specific example where the arrow function actually shines. It's specifically I think the reason why It's the thing that gave it enough weight to make it into the language. I wasn't on the committee so I'm not speaking officially there but I'm just saying personally, this is the reason why I think it deserved to be included in the language even if it's not my general, arrow is the new function replacement.
[00:04:56] And it's for cases like this, let's say that I have
>> Kyle Simpson: A function foo that at some points set time out and it does another function here
>> Kyle Simpson: And let's say that this is the property of some object.
>> Kyle Simpson: And what I want to do is have some property on here like ID 42 and then I want to be able to say after 100 milliseconds, I want you to print out this.id.
[00:05:42] Okay. Okay so I wanna be able to say something like the obj.foo and after a 100 milliseconds I want it to be able to print out the value 42. If you've ever dealt with this keyword before, you know exactly what's going to happen here, the function that's invoked by the set timeout is going to be invoked.
[00:06:00] Using the default binding rule check out my this and object prototypes book if you want to know more about this keyword but it's invoked with the default binding rule as a matter of fact actually by spec the set timeout invokes it explicitly in the window context but the same result is that this keyword is not pointing at OBJ this keywords pointing at our global object.
[00:06:20] Not what we want. So we're going to end up getting undefined instead of 42. That sucks. So the way people mostly solve this is to say something like var self equals this and then they use self here. First off that's a terrible fun variable name cuz now this keyword does not ever in any circumstances that you ever run into refer to the function itself.
[00:06:43] Just doesn't. That's a bad variable name. Because we couldn't come up with anything else. We were uncreative like we are. You should have been calling it context, cuz that's what it really is. It's a dynamic context. It's an object context. So if you called it context at least it would be able to complain about the variable name.
[00:06:58] But the other problem here is you've gone to the trouble to have all this this based coding and now you've fallen back to non the space coding lexical variables. The real solution to this problem although solution that embraces the language the way it is is to use, the dot bind utility.
[00:07:17] Nobody likes to write dot bind this all over the place. I fully understand why that sucks. As matter of fact somebody had proposed the double colon operator to try to get away from having to type dot bind. But this is that place. If you've been writing var self equals this in some part of your code, or dot bind this in some part of your code, this is that place where the arrow function shines cuz the arrow function doesn't have of this keyword in it.
[00:07:41] It can't be bound to a this keyword. So if you reference that this keyword inside of an arrow function, it will automatically lexically go up one level two of scope and use that this keyword in the surrounding scope. Doesn't have its own this keyword. So if all we did was just change this into an arrow function
[00:07:59]
>> Kyle Simpson: With or with those curly braces, I'm gonna put them there just for clarity. But if we took that out,
>> Kyle Simpson: Sorry my indentation is all messed up here. All we did was make it an arrow function. Now all of a sudden the this keyword starts working correctly or working the way we would assume it to work.
[00:08:18] The arrow function doesn't have its own list, so we automatically get a lexical list. That's where arrow function shines. If you're using this space coding and your running under those of var self equals this or dot binds, you have my full faith and support to go start using arrow function in those places.
[00:08:35] You're gonna to have to be careful when you're mixing arrow functions and non-functions okay? And the exercise I'm about to have you go through is gonna teach you that lesson. You're gonna have to be real careful about exactly what scope is the arrow function going to adopt from.
[00:08:50] But arrow functions by themselves really do shine in this particular case. They solve this particular problem. Actually we don't even need the curly brace here. The curly braces in this particular case are optional because the console log method call is also an expression. So there we wouldn't even need it, we would have to take out the semi colon, okay.
[00:09:09] With or without the curly braces, it's going to adopt to this keyword from the outer scope. So that's why you ought to be using arrow functions, but I don't necessarily think that they shine in terms of general replacement for all function usages.