This course has been updated! We now recommend you take the Angular 9 Fundamentals course.
Transcript from the "Better Variables" Lesson
[00:00:00]
>> [MUSIC]
[00:00:04]
>> Scott Moss: Of course we left off on importing dependencies and what not right. And if you were to look in home.js, you might have saw something funky like this const, right. Anybody see that and went over to Babel and try it out and figure out what it was? So we're gonna talk about that, talk about better variables, and ES2015.
[00:00:26] So, can anybody tell me one thing about var that they didn't like? Yes.
>> Speaker 2: It's overwritable all the time.
>> Scott Moss: It's overwritable all the time, anything else? One thing that doesn't seem out, yes?
>> Speaker 2: Scoping is a little bit weird, it's hoisted.
>> Scott Moss: Exactly, that's the worst part.
[00:00:51] Scoping is, var is not what you think it is, right. It hoists differently, it recognizes scopes differently, doesn't have local scope, it's kinda whatever it wants to be. Because if you know JavaScript then you know the way that JavaScript reads its code. If I had some code here and I said var name and var thing equals something.
[00:01:12] The way JavaScript is gonna read this is that it's first gonna come here and say okay var name, gotcha, var thing, gotcha. And then it's gonna come down here and say name thing, right. That's how JavaScript reads this. So it hoisted those variables to the top of the scope and set their value as equal to undefined or no values.
[00:01:31] And then to reassigned their values later on. So that's why scoping is really weird, and that's how those variables are available somewhere else where you didn't think they were, right. So, same thing with functional expressions. If we did something this, this gets hoisted all the way to the top.
[00:01:48] Not even just the value but the actual function itself is available up here. And now I can do this, right, that's that's really crazy, right. So that happens too because this gets hoisted all the way to the top so, funny things. So now what we can do is we can use better variables.
[00:02:06] And we can use them in two different ways. So we can use let and const, right. So both let and const have local scoping and they don't hoist and const is also immutable. So what that means is, is this. So I can just say let val equals one.
[00:02:25] Const nums equals all this stuff. [INAUDIBLE] And what I can do now is if I say I have this conditional, if true, let val equals hey. So I changed whatever val was, right, I definitely changed it here. I'm like yo you're something different now, right. But when I come down here and I want to see what val is, it's actually not this, it's whatever it was up here.
[00:02:51] And that's because this value right here is being held in closure through this scope right here of these brackets of the if statement whereas of var would not, right. So this also applies for const, const will behave the same way too. The only extra benefit of const is that it's immutable, so const is an array.
[00:03:13] So I'm pushing numbers into it, which is fine, I'm not changing it. It's still an array, I’m not changing its value. It's still in array, I'm just pushing numbers into it, that's totally fine. But then if I try to reassign its value to something else like another empty array, it'll like nope, you can't do that.
[00:03:27] It'll break, won't let me do that, right. So if I head over and show you what that looks like, so I say const nums 1, 2, 3, right. And then I say, nums.push(1), okay, nothing there but then I say nums equals that. See that at the bottom right there?
[00:03:52] Nums is read-only, all right.
>> Scott Moss: It's pretty crazy. So that's how that works and that happens at runtime.
>> Scott Moss: So those are what we're gonna use. So how do you know which ones to use and which ones not to use? In the context of this what I've learned from using this and after talking with many people.
[00:04:17] I think it's best just to use const for everything unless you have to change it. Unless you absolutely have to change the thing which is not uncommon, right. That happens a lot, you have to change the value. Maybe you need this thing to be hoisted and then through some conditionals, you're gonna change the value, you would use let.
[00:04:35] But for everything else, I would use const. And then on the rare cases that you need the thing to hoist all the way up to the top or whatever, then you would use var. But my argument is if your code is doing that, then it's probably hard to read so you shouldn't be doing it anyway.
[00:04:50] So I haven't run into a condition where I needed to use var, I'm using just const and let. Yes?
>> Speaker 2: No, go ahead and finish your thought, but I'll ask a question.
>> Scott Moss: But it doesn't mean that you should go and change all your vars to let and const, cuz you will break stuff, you will break stuff.
[00:05:04] Yes?
>> Speaker 2: So there's a question online that I think it would be great for you to explain orally. Why did push not throw an error?
>> Scott Moss: Good question, so let's go back.
>> Scott Moss: So const, we're making a variable called nums who is defined by the key word const.
[00:05:25] And it's array, or I'm sorry, its value is an array, which is an object, right? They have properties, they have indexes, it's a collection. So when I say nums.push, I'm only adding a value to the collection. Remember the collection, the array is the value of nums, that's the actual value.
[00:05:43] It is the array itself and I'm only adding things to that collection. So I'm not changing the actual value, it's still an array. If I were to say nums.push and then check it against itself, it'd still equal itself. It's still the exact same array in memory, it's just got some more values in it.
[00:05:57] So I'm not changing the values of nums but on line six, I am. I'm saying nums is now equal to a new array. I can also say it's a new string and it's still gonna break cuz now I'm reassigning what nums was. Whereas before I was just modifying some values inside of it, so.
[00:06:14]
>> Speaker 2: So you can change its type?
>> Scott Moss: Change its reference.
>> Speaker 2: No you can't change its object.
>> Scott Moss: Right, yeah, you can't change-
>> Speaker 2: The memory location.
>> Scott Moss: You can't change its value.
>> Speaker 2: You can give it a pointer, right? Like nums is the pointer to some thing.
[00:06:28] So you can change what's in that thing you're pointing at.
>> Scott Moss: Exactly.
>> Speaker 2: It's like you can change, if nums was an object and it had three keys.
>> Scott Moss: Yes.
>> Speaker 2: Key a is equal to one, you can set nums.a equal to two and that's not technically changing nums.
[00:06:43]
>> Scott Moss: Exactly, yeah, so it's-
>> Speaker 2: You want to protect the values of the object, you use freeze.
>> Scott Moss: Yes, object.freeze, that's, forgot about that one.
>> Speaker 2: That's more in the concept of an immutable array or object whereas this is an immutable pointer? I don't know.
>> Scott Moss: Yeah, it's in the middle, a little compromise there, yeah, so it's not, yeah exactly.
[00:07:04]
>> Speaker 2: Horatio is asking if pop would crash. It would not, correct?
>> Scott Moss: Ppo would not crash, it's the inverse of push so yeah, it'll be fine.
>> Speaker 2: Because it's the same thing basically, nums is still pointing at the same array, it's just that that array is changing.
>> Scott Moss: Yep, it would be totally fine, nums.pop [SOUND].
[00:07:24]
>> Scott Moss: Cool, any other questions on that?
>> Scott Moss: Cool, okay, so yeah, use const for everything unless we need to change something. I think, actually, I know AirBNB, who has probably one of the best JavaScript style guides just updated their style guide to say the exact same thing. So that's how I knew I was onto something when they said it.
[00:07:42] So yeah, use const for everything unless you absolutely have to change it. And then if you have to use var, look at your code first to make sure that it's nice and neat to read. And if you think it is and someone else looked at it, then use var.
[00:07:56] But I don't know if you would ever even need it anymore. But like I said, do not go back and change var to let because you want to be cool, right, just don't. I did it and it doesn't work all the time, so.
>> Speaker 2: It's only if you're using a transpiler, right?
[00:08:09]
>> Scott Moss: Yeah, well even if you have existing code now, let's say you have ES5 code now and you're like, I want to start using ES6 today. [INAUDIBLE] add a transpiler build system to it. Now everything from here on out is ES2015 and you have that mixed with ES5.
[00:08:22] And then you go back and you start refactoring ES5 to use let and const. That's when you start problems, right, so don't do that.