This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.
Transcript from the "Quiz: this" Lesson
[00:00:00]
>> [MUSIC]
[00:00:04]
>> Kyle Simpson: So quiz time. Without cheating and looking back at that slide I want you to tell me those four rules in order. What are they? New, explicit binding with a caller apply or a bind, implicit binding with and owning or containing object, default rule. Was there a question from the chatroom?
[00:00:25]
>> Speaker 2: No, I was-
>> Kyle Simpson: Okay.
>> Speaker 2: Being a smartass.
>> Kyle Simpson: All right. Those are our four rules in order. How do you borrow a function through implicit assignment of the this? How did the implicit binding work?
>> Speaker 3: When you call the function, it was in the context of an object, so it head and puts it on.
[00:00:45]
>> Kyle Simpson: Right, we mutated an object to put a reference to that function on the object, so that we could then say object dot method name. Exactly. So sometimes it's okay to put a method reference on an object, and kind of implicitly borrow it, other times that's kind of awkward, but that is a way to implicitly bind.
[00:01:02] How do you explicitly bind the this keyword?
>> Speaker 3: Call in a collide?
>> Kyle Simpson: Call in a collide bind implies that it does a [INAUDIBLE]. How can we seal a specific this to a function?
>> Speaker 3: By using the bind function?
>> Kyle Simpson: The .bind utility. Now, why was that beneficial, what was the usefulness of doing that hard binding?
[00:01:29]
>> Speaker 4: We want to constrain this to an explicit version.
>> Kyle Simpson: If you want it to be predictable. You want your methods to always go against a particular object, you're annoyed that it's always getting lost, creating a hard-bound reference to that solves that problem for me. So that's a good thing, what's the downside of this?
[00:01:45]
>> Speaker 4: You loose flexibility.
>> Kyle Simpson: Yeah, the trade-off, you lose. I want you to ask this as a thought question, if you go to all the trouble to put hundreds of annoying this dot references all over your code base, and then you find yourself doing everything with hard binding.
[00:02:01] Why did you do a this binding, why didn't you just use lexical? Because you're going down this harder path and then cutting off all the flexibility which is the whole benefit and the reasoning you use that mechanism. There two separate mechanisms, they have two separate capabilities and trade offs, and things like that.
[00:02:17] Hard binding is one of those sort of cheating things where you're fixing one problem, but you're trading off that you're losing that flexibility. So I'm not saying that hard binding's wrong, I use it from time to time. But if you find yourself doing most of your code with hard binding, you might want to ask yourself, maybe I shouldn't use the this keyword at all, cuz maybe I'm doing it the harder way.
[00:02:38] Lastly, how do you create a new this object?
>> Speaker 4: [INAUDIBLE] Can new key.
>> Kyle Simpson: Not a trick question, by using the new keyword. Exactly, by using the new keyword. All right, so that's our this mechanism. And again to reinforce you can see that the this mechanism is dynamic.
[00:03:00] It's a binding mechanism that looks for things at runtime, it's entirely based upon how you called something. You can have the exact same function called in four different ways and get four entirely different bindings, does that make sense? So that's the contrast between that lookup mechanism, and the lexical scope mechanism which was hard coded at author time.
[00:03:23] It's not dependent upon how something's called or where, it's only dependent upon where it's declared. Where you put those nested scope bundles.