Check out a free preview of the full TypeScript Fundamentals course:
The "Variable Declarations" Lesson is part of the full, TypeScript Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Mike examines the specifics of variable declarations var, let and const for reassigning, scope, and hoisting.

Get Unlimited Access Now

Transcript from the "Variable Declarations" Lesson

[00:00:00]
>> Mike North: When we talk about how we can store values and use them in our programs, we need variables, and there are three different ways to declare variables in a modern JavaScript program. We've got var, let and const. So with var declarations, there is a phenomenon called hoisting, and that basically means that even if we declare a variable low down, and they function scope or within a block inside a function scope.

[00:00:28] That variable declaration is hoisted, it's brought up to the top of whatever function scope it belongs to. So, even if this were inside an if which will see I think on the next slide, it gets brought up. We have, so the convention here is on the left. We've got code that you write in your app.

[00:00:47] And on the right, this is a code that the browser sees, that's why we've put it in the browser. This is how a run-time understands it. This why we have a bunch of linting, like static analysis, rules that will say, please make sure that you declare your variables at the top of your function scope.

[00:01:06] We've basically said, make sure your code looks like what we have on the right, so there's no misalignment between left and right. So we've solved this by basically conforming to the way the language or the way runtime thinks. And bent our code to meet that, so there's no miss alignment.

[00:01:28] Var declarations are not block scoped, meaning that this y that we have here, that's actually gonna have the value even outside of the condition that it is used in, that it is set in, right? So this can lead to some strange problems where sometimes we'll pass through a particular block and sometimes we won't.

[00:01:50] And you can end up with side effects that linger on in ways you don't expect. So they are function scoped, not block scoped. And this is unintuitive for a lot of developers, like most. If you're coming to JavaScript from another language, you would expect y to only have any meaning, or significance, or value within that condition.

[00:02:16]
>> Mike North: With the 2015 version of the JavaScript language spec we got let. Let declarations are not hoisted, and there are some tricks that compilers and transpilers like Babel or Typescripts do to enforce this for us even we're building Javascript for IE6, right? Even if we're building really like old Javascript.

[00:02:41] We accomplish this by creating what's called the Temporal Dead Zone, it is a fancy term for basically renaming variables so that we can be assured, x will have no meaning before that line of code. In a moment we'll show you how this is converted and how we accomplished this.

[00:03:02] The end result is, in this situation, we're trying to use x before it's defined and we get an error instead of, but we would've gotten where there's a var or you would've seen the value undefined, long to the console, right? So let decorations are block scopes, meaning down here we're also going to get a similar error because we're trying to use y.

[00:03:29] Y has no meaning outside of the block that's attached to that condition.
>> Mike North: Const behave similarly, it behaves in terms of scope and hoisting, it behaves very much like let. The twist here is that once you assign, like once you set a value to a variable that's declared with const, you cannot reassign it, right?

[00:03:57] So if you say const x equals 15, you can't point x to anything else. It's important to understand that when we talk about not being able to change things, the ability to re-assign something is a separate Idea from whether the value of something is mutable or immutable. Does that make sense to everyone?

[00:04:22] So for example, if we have, we talked about how a string, that's an immutable value type in JavaScript. We can't change a string if we split a string, we're really creating new strings. So if we say, const x equals Mike, that's an immutable string value, and we can't point X to anything other than the string that we pointed to in the first place.

[00:04:46] Now if we havd something like an object or an array, we can't point to a different object to an array, but we can certainly change the contents of that object to an array, we'll see more of this later on. If you want to have something that is like both not reassignable and the value is not changeable, you can use something like object.freeze.

[00:05:11] What that does is effectively it will return a copy of an object that is sort of locked in place. You can't add any new properties to it and you can't change any existing properties. So if you've ever heard of something like immutable js, this is gonna give you something akin to that, right?

[00:05:30] It will give you for example a read-only array, and there now you're both immutable and constant. So in summary, we can think of our declaration, ability to declare things as having 3-dimensions here. Everything except const can be reassigned, so if you have let x = 17, you can set x equals to other things, same with the var.

[00:05:58] Const, you cannot do that with. Var is function scope, right? That's the one that gets, that'll sort of bleed out of the blocks where they're defined in. Whereas let and const, they're the ones that'll throw those errors if we try to use them outside the block where they're defined.

[00:06:16] And then finally there's that strange hoisting phenomenon that happens with Var, and that does not happen with let and const.
>> Mike North: So most of the day today, we're gonna be working with let and const, but I do want you to understand how var works because you may see it.

[00:06:35] And what we try to do Is the use of var if we must use it, we use it in ways where it aligns with like basically our code shows it is already hoisted, right? Our variable declarations are always at the top of our function scope.