Block Scoping

[00:00:00]
>> Kyle: We've talked about function scoping, let's shift our attention now to block scoping. Block scoping like it sounds, it's scoping that's done with blocks aka curly braces instead of with functions. Same principle is gonna apply. We wanna put something inside of a block instead of inside of the enclosing scope because we wanna hide it, so that it has fewer chances of name collision.

[00:00:25]
We wanna protect a detail, protect future refactoring, all the same principle applies. It's just the mechanism we use is now a block scope declaration instead of an IIFE, for example. So Instead of writing an IIFE, let's write it with a block. And you can compare mentally the difference between that example with an IIFE or just using a curly braced block and using a let statement like a block scope decoration,

[00:00:56]
>> Kyle: It's a lot lighter weight isn't it?. It also has less side effects in the sense it doesn't redefined anything about returns or breaks or any of that other stuff, so blocks are a bit easier and lighter weight to put into places. They're not expressions, so you can't use them in places where you can use expressions.

[00:01:15]
But if you have them in a place that's a statement, it's totally okay. And sometimes often a lot more preferable to just do this lighter weight form, wrap a curly brace pair around something and make a block scope declaration inside of it. Now you can't just do a var here because historically vars have been attaching themselves to the outer function scope or global scope.

[00:01:37]
So a var here would have attached itself to the outer scope rather than the curly brace pair.
>> Kyle: Instead of breaking old backward or old previous code, they decided to add new declaration forms. So it's where we get the let and the const from. Let and const are so that you can make a declaration inside of a block and it turns that block into a scope.

[00:02:02]
Blocks are not scopes until they have a let or const inside of them and then that sort of implicitly makes them a scope. That's a key place where people sort of get, they think that all curly braces are scopes, and they're not all scopes. They're only a scope if there's a let or a const inside of it.

[00:02:23]
Okay, so this was a lightweight way of doing this particular example. But where does block scoping fit in the larger scope of things? I'm gonna make the claim that what you should be doing with block scoping is using something like the let keyword to reinforce something that you would have already naturally wanted to signal to your reader.

[00:02:44]
Here's an example. If you were writing code where you had an if statement that needed a temporary variable to do something, in this case to swap two values. And you called it tmp to signal to the reader, it's just a temporary placeholder, I'm not really using it for much.

[00:03:00]
And definitely, I put the var tmp inside of the if because I'm trying to say to the reader, you don't need to access this or use this anywhere else. We know that the way var behaves is that it'll attach itself to the blue scope, right? It'll be a blue marble attached to the whole function if.

[00:03:19]
But we're signaling something stylistically, semantically to the reader which is to say this variable belongs to the if statement. If you do stuff like this, and some of you may have put your vars inside of if statements or other sorts of blocks before or maybe you put your var statements inside of for loops.

[00:03:38]
That's a very common thing. If you've done that, then what you were already signalling was, whether you realized it or not, hey reader, this is a block scoped variable. And now that we have a block scope declaration, you can safely replace those and now you are enforcing the thing that you were already stylistically signalling.

[00:04:01]
That I think is the appropriate way to approach this feature which is to say, you should use it in places where it is already obvious and correct design for you to block scope something. I do not think that you should go looking for opportunities to more complexify your code by having more block scoping for no particular reason, just so you can use this hot new let keyword.

[00:04:28]
You should use it in places where it already makes sense to block scope, okay? So that's the first shift that I wanna have in your mental thinking is to think about that as a replacement for your already semantically signalled block scope. I'm not a big fan by the way of this hijacking of scopes because I normally think of an if statement as just an if statement.

[00:04:54]
But now I have to look through the entire contents of an if statement to figure out if there's a let keyword in it and figure out if that's also a scope. And if it is a scope I have to be more careful about what I move around and where I can put what.

[00:05:08]
So I'm not a big fan of that whole implicit hijacking thing but I am a fan of being able to enforce the thing that we were already signaling which is, I want this thing to be local. So what about this whole let is the new var thing? I'm sure you've heard this before, as a matter of fact that's been replaced even with const is the new let.

[00:05:30]
There were literally T-Shirts made, and worn by some members of TC39 years back that said, let is the new var. This was a banner. And there was a blog post by a TC39 member that said, just do a global find and replace on your program and replace all occurrences with var with a let.

[00:05:49]
That is an enormously stupid piece of advice. Please do not do that. It's a terrible idea. Not only are you almost certainly to create bugs, but importantly than that, you're misusing that feature. Consistent with everything you've already seen from me in this course, I'm gonna tell you that let is not just some across-the-board replacement of the var keyword.

[00:06:14]
But it is an additional tool that we should add on to our existing usage which means that there are still reasons to use the var keyword. And that is similarly controversial or unusual compared to my peers who would tell you never, ever, ever use the var keyword ever again.

[00:06:34]
And I'm gonna keep telling you the var keyword has purpose. Here's an example. In this code, we have two vars. We have a var that's on a for loop, and we have a var that's essentially being used across the entire function.