作者:Dmitri Pavlutin
翻译:疯狂的技术宅
来源:dmitripavlutin
我问一个简单的问题。以下哪个代码片段将会产生错误?
第一个创建实例,然后定义所用的类:
1new Car('red'); // Does it work?
2
3class Car {
4 constructor(color) {
5 this.color = color;
6 }
7}
第二个先调用然后定义函数:
1greet('World'); // Does it work?
2
3function greet(who) {
4 return `Hello, ${who}!`;
5}
正确答案:第一个代码段(带有类)将生成 ReferenceError
。第二个工作正常。
如果你的答案与上述不同,或者在不知道底层发生了什么的情况下进行了猜测,那么你需要掌握临时死区(TDZ)。
TDZ 管理 let
,const
和 class
语句的可用性。对于变量在 JavaScript 中的工作方式非常重要。
让我们从一个简单的 const
变量声明开始。如果首先声明并初始化变量,然后访问它,那么一切都会按预期进行:
1const white = '#FFFFFF';
2white; // => '#FFFFFF'
现在让我们试着在声明之前访问 white
变量:
1white; // throws `ReferenceError`
2const white = '#FFFFFF';
3white;
在到 const white = '#FFFFFF'
语句的代码行之前,变量 white
位于时间死区中。
在 TDZ 中访问了 white
之后,JavaScript 会抛出 ReferenceError: Cannot access 'white' before initialization
。
JavaScript中的临时死区
TDZ(Temporal Dead Zone)语义禁止在声明变量之前访问变量。它强制执行纪律:在声明之前不要使用任何东西。
让我们看看受 TDZ 影响的语句。
正如你已经看到的,const
变量在 TDZ 中声明和初始化行之前:
1// Does not work!
2pi; // throws `ReferenceError`
3
4const pi = 3.14;
你必须在声明后使用 const
变量:
1const pi = 3.14;
2
3// Works!
4pi; // => 3.14
在声明行之前,let
声明语句也会受到 TDZ 的影响:
1// Does not work!
2count; // throws `ReferenceError`
3
4let count;
5
6count = 10;
同样,仅在声明后使用 let
变量:
1let count;
2
3// Works!
4count; // => undefined
5
6count = 10;
7
8// Works!
9count; // => 10
从简介中可以看出,在定义类之前不能使用它:
1// Does not work!
2const myNissan = new Car('red'); // throws `ReferenceError`
3
4class Car {
5 constructor(color) {
6 this.color = color;
7 }
8}
为了使它起作用,请在定义后保留类用法:
1class Car {
2 constructor(color) {
3 this.color = color;
4 }
5}
6
7// Works!
8const myNissan = new Car('red');
9myNissan.color; // => 'red'
如果扩展父类,则在构造函数内部调用 super()
之前,this
绑定位于 TDZ 中:
1class MuscleCar extends Car {
2 constructor(color, power) {
3 this.power = power;
4 super(color);
5 }
6}
7
8// Does not work!
9const myCar = new MuscleCar('blue', '300HP'); // `ReferenceError`
在constructor()
内部,this
在调用 super()
之前不能使用。
TDZ 建议调用父构造函数来初始化实例。完成之后,实例已准备就绪,你可以在子构造函数中进行调整。
1class MuscleCar extends Car {
2 constructor(color, power) {
3 super(color);
4 this.power = power;
5 }
6}
7
8// Works!
9const myCar = new MuscleCar('blue', '300HP');
10myCar.power; // => '300HP'
默认参数存在于 intermidiate 作用域内,与全局作用域和函数作用域分开。默认参数还遵循 TDZ 限制:
1const a = 2;
2function square(a = a) {
3 return a * a;
4}
5// Does not work!
6square(); // throws `ReferenceError`
在声明前,在表达式 a = a
的右侧使用参数 a
。这会产生关于 a
的引用错误。
要确保在声明和初始化之后使用默认参数。让我们使用特殊的变量 init
,该变量在使用前已初始化:
1const init = 2;
2function square(a = init) {
3 return a * a;
4}
5// Works!
6square(); // => 4
与前面相反,var
和 function
的定义不受 TDZ 的影响。它们在当前作用域内被提升。
如果在声明之前访问 var
变量,则只会得到 undefined
:
1// Works, but don't do this!
2value; // => undefined
3
4var value;
However, a function can be used regarding where it is defined: 但是,可以使用函数定义其位置:
1// Works!
2greet('World'); // => 'Hello, World!'
3
4function greet(who) {
5 return `Hello, ${who}!`;
6}
7
8// Works!
9greet('Earth'); // => 'Hello, Earth!'
通常来说你对函数的实现不太感兴趣,而只是想调用它。所以有时在定义函数之前先调用该函数是有意义的。
有趣的是, import
模块也被提升:
1// Works!
2myFunction();
3
4import { myFunction } from './myModule';
import
时,在 JavaScript 文件的开头加载模块的依赖项是一个好的做法。
typeof
运算符可用于确定变量是否在当前作用域内定义。
例如,变量 notDefined
未定义,在这个变量上应用 typeof
运算符不会引发错误:
1typeof notDefined; // => 'undefined'
由于未定义变量,因此 typeof notDefined
的值为 undefined
。
但是当与临时死区中的变量一起使用时,typeof
运算符有着不同的行为。在这种情况下,JavaScript 会报错:
1typeof variable; // throws `ReferenceError`
2
3let variable;
这个引用错误背后的原因是,你可以静态地(仅通过查看代码即可)确定已经定义了variable
。
临时死区会在存在声明语句的作用域内影响变量。
JavaScript中的临时死区限制
让我们来看一个例子:
1function doSomething(someVal) {
2 // Function scope
3 typeof variable; // => undefined
4 if (someVal) {
5 // Inner block scope
6 typeof variable; // throws `ReferenceError`
7 let variable;
8 }
9}
10doSomething(true);
There are 2 scopes: 有 2 个作用域:
let
变量的内部块作用域在函数作用域内,typeof variable
仅计算为 undefined
。在这里, let variable
语句的 TDZ 无效。
在内部作用域中,在声明之前使用变量的 typeof variable
语句引发错误ReferenceError: Cannot access 'variable' before initialization
。TDZ 仅存在于此内部作用域内。
TDZ 是一个重要概念,会影响 const
,let
和 class
语句的可用性。不允许在声明前使用变量。
当你可以在声明之前使用 var
变量时,它们会继承旧的行为。你应该避免这样做。
在我看来,当把良好的编码实践进入语言规范时,TDZ 就是其中的一个好东西。
原文:https://dmitripavlutin.com/javascript-variables-and-temporal-dead-zone/