Context

[00:00:00]
>> Brian Holt: Context. Don't want to dwell too much on this. Again, Frontend Masters has some really great courses on some of the deeper JavaScript fundamentals, which I would suggest taking after you watch this. Particularly anything from Kyle Simpson.
>> Brian Holt: But let's say that I had some object. And it'd be really nice rather than having to individually have to rewrite addresses over and over again.

[00:00:30]
This happened to me when I was doing like working on an e-commerce site at Reddit. I didn't want to have to write someone's address every damn time that I needed to. So I wrote functions that given an object would generate an address, right? So I have this thing here that lives on 500 Fakestreet.

[00:00:46]
I'm not dumb enough to put my address up here. [LAUGH] And then I have a function here called getAddress, right? And so now if I call console.log.getAddress. You'll see here that it actually prints a convincing looking American address, right? So this is a very finicky beast, it's a source of many bugs.

[00:01:10]
And I will say that even many mid and senior-level developers don't fully grasp what this is doing at any particular time. So in this case, [LAUGH] it's contextual, right? That's kind of the point, I think this belies that fact, right? But if I say this.name.first, right? It's referring to the object that it's currently in, right?

[00:01:35]
So if I say this.name, it's referring to name, right? So you can think of this in this particular case, this is a tongue twister, as me, right? So this is referring to whatever object it's on. And that's kind of the gist of behind what this is supposed to be.

[00:01:55]
So in this case, it's very clear that this refers to me. That's pretty obvious, right? But it can get so much more complicated. And sometimes, it becomes very unclear of what this can be.
>> Brian Holt: So for example, if I put a function here,
>> Brian Holt: console.log(this), what do you think that this is going to be?

[00:02:25]
>> Speaker 2: Name?
>> Brian Holt: It's gonna be the name object, so let's just me., I'll just put it above it. console.log.me.name.logMeOut.
>> Brian Holt: So there you go. It's actually going to end up being name. So it's a little, perhaps counter-intuitive or maybe it's intuitive to you, yeah?
>> Speaker 3: Sorry, if you just answered this but why is it this instead of putting just me.name.first?

[00:03:00]
>> Brian Holt: Because they're not always going to have access to me in that particular scope, right?
>> Speaker 3: Okay, so this just references the object that it would be talking to in a more generic sense?
>> Brian Holt: Yeah, I think that's a good way of putting it.
>> Speaker 4: And do you need to create the function inside the object to use it?

[00:03:16]
Or can it be created outside?
>> Brian Holt: It's possible to create it outside of it. Let's not talk about that, but in general it'll be created inside of the objects, yeah, yeah.
>> Speaker 4: So it looks like if you want to make an object, you write it out like this, and I can make const me or const Brian, const Emma, whatever and write all of this.

[00:03:40]
If I know that I'm gonna need a whole bunch of user profiles, or a whole bunch of people objects, do you not have to start with a generic, a person has a first name and last name and this method [SOUND] and then make instances? Can you just make up a bunch of instances without the first part?

[00:03:56]
>> Brian Holt: Right, so in other programming languages, you have to be a little bit more disciplined about how you declare it. And you have to declare, this is gonna take in strings and give back numbers, and that kind of thing. JavaScript doesn't even let you do that.
>> Speaker 4: Wow.

[00:04:10]
>> Brian Holt: Yeah, it's purely dynamic in nature, which is great because there's a lot of circumstance and rituals that you don't have to do, right? Like writing header files in C++ and that kind of stuff, right? If I never have to write another one of those again, I'll be happy.

[00:04:25]
[LAUGH] But at the same time that kind of thought process helps, right, because you can kind of see how your program's flowing, what it expects, kind of the contracts between different parts of your program. So it is a trade off. You end up with more bugs, I would say.

[00:04:38]
>> Speaker 4: If I need 500 people, I'm gonna write that stuff out 500 times.
>> Brian Holt: Or you could write a function that generates people.
>> Speaker 4: Right.
>> Brian Holt: Yeah.
>> Speaker 5: And so by declaring it, const me, you wouldn't be able to make all the changes that you're making to this in a normal situation.

[00:04:59]
>> Brian Holt: You guys are asking all the good questions today. So, what trips people up about const, I would say, is probably const's biggest strike against it, is I can still say me.name=or.first, we'll put Niki in there, right?
>> Brian Holt: So it's not frozen. This object is not frozen, however, I cannot say, me = something else, right?

[00:05:32]
This is reassigning me. And so that right there is gonna say type error. You tried to reassign me. However, I can totally change things inside of the object. So now, if I say console, actually, I just do this again, right?
>> Brian Holt: You'll see down here that now it's Niki Holt.

[00:05:58]
>> Brian Holt: So that's confusing for a lot of people. It's just something you have to get used to. It basically means that you can't reassign it at the top level, right, but you can meddle around with the things inside of it. So yes, that's what this is. If you see it, that's what it means.

[00:06:20]
It's basically referring to the object around it, but sometimes, you can get kind of messed up and this can be called in strange circumstances then you don't know what this is gonna be. So another good example of that, if I said console.log, this right here, what do you expect it to log out?

[00:06:39]
>> Brian Holt: I mean, the answer is it's nonsensical, right? So it doesn't really matter. Okay, let's delete that. I think it should be Window, but I don't actually know what this library is gonna do with it so I don't really know. [LAUGH] I don't know what context this is being called in.

[00:06:56]
And I think I just crashed it.
>> Speaker 3: Okay.
>> Brian Holt: So it doesn't really even know what to do about that. Yeah, but often you can't predict what this is gonna be. So if I come back in here and trash that. Now, if I put this here, what would you expect it to be?

[00:07:14]
That's tough too but it's gonna be the window. Window is like the whole page, right? So if I said this.,
>> Brian Holt: Date, which is one of the functions that's built onto the window, right? So it can be pretty tough to predict. And sometimes, you can even call a function like this one that we have in here, wherever this is.

[00:07:45]
This one right here. And if I don't call getAddress the correct way, I can break it and this will become something else. So I'm trying to underline the fact that this can be very complicated. And so whenever you're using this somewhere, just know that you're stepping into a minefield.

[00:08:02]
>> Speaker 4: I was going to ask, do you ever use this to figure out, I guess, where you are, or what the scope is at any given time, or is that dangerous?
>> Brian Holt: No, I mean, if I was in debugging I wouldn't ship that to production, right? But yeah, I've done that before.

[00:08:17]
I'm not above that. [LAUGH] But yeah, I can show you here, let's see if I did. So, setTimeout is a function that whatever you call it, it'll wait in the next key to function. And then, if I call this.me.getAddress and I did wait 1000 milliseconds which will wait one second,

[00:08:50]
>> Brian Holt: It's probably not gonna try and execute that, is it? Well, it wouldn't know how to deal with that but we'll just put this in my console here. So now I have me over here.
>> Brian Holt: Okay, trash that. And then I'll put this in my console.
>> Brian Holt: And actually, it is working but nothing is happening, right, because all of these are undefined.

[00:09:24]
>> Brian Holt: Or it's just erroring out. In any case, it's not gonna work because whenever you do a set time out like this, it changes the context. Which you can fix but I'm not gonna show you. [LAUGH] Suffice to say it's a minefield, right? So, general rule of thumb is that this is going to refer to whatever object it's on, and that you should worry about it.

[00:09:54]
That's kind of my sum of my story here, Laynee?
>> Speaker 3: What would be recommended if you had to delete declared variables using let and const statements? Are there any delete keywords in JavaScript?
>> Brian Holt: Yeah, just delete. [LAUGH] So here. I never do this. I can't really fathom times that I've had to do this, but it is possible.

[00:10:24]
So let's say that for whatever reason I wanted to delete the name or something like that. You can say delete me.name. And then, whenever I call, obviously this.name underneath here is gonna be undefined. So you can't access properties on things that are undefined.
>> Brian Holt: But this does work, you never have to do it.

[00:10:51]
>> Brian Holt: This is actually something good to talk about, though. So I have an object here, console.log(me), right?
>> Brian Holt: And then, if I have me.name, but maybe I was thinking, a name. It should have a middle name, right? And I put .middle, okay? And then, maybe I wanted that in uppercase,

[00:11:15]
>> Brian Holt: Right, the first thing it's gonna say here is, you can't access something on something that's undefined, right, middle is not a thing. So that's when I get me.name.middle is undefined, right? So whenever you see something like that, an error like that, probably means that you're trying to access something that doesn't exist.

[00:11:34]
Or another one here is maybe I was assuming that middle was a function and so I put those parenthesis there, and it's gonna say undefined is not a function. So that's another one that you'll frequently see. It's a common mistake to make.
>> Brian Holt: That's why. You can't invoke something that's not a function.