Baseline Widely available
**let
**ç¨æ¼å®£åä¸åãåªä½ç¨å¨ç¶ååå¡çè®æ¸ãï¼åå§å¼å¯é¸ææ§çè¨å®ã
let x = 1;
if (x === 1) {
let x = 2;
console.log(x);
// Expected output: 2
}
console.log(x);
// Expected output: 1
èªæ³
let var1 [= value1] [, var2 [= value2]] [, ..., varN [= valueN]];忏
var1
, var2
, â¦, varN
è®æ¸å稱ã
value1
, value2
, â¦, valueN
è®æ¸çåå§å¼ï¼å¯ä»¥æ¯ä»»ä½åæ³ç表éå¼ã
let
å¯ä»¥å®£ååªè½å¨ç®ååå¡ãéæ®µæè¡¨éå¼ä¸ä½ç¨çè®æ¸ãè var 忝å®ç¾©äºä¸åå
¨åè®æ¸ï¼ææ¯å¨æ´å function èä¸ç®¡è©²åå¡ç¯åã
宣å let
çä½ç¨ç¯åæ¯å®å被å®ç¾©çåå¡ï¼ä»¥å該åå¡å
å«çååå¡ã鿍£çèµ·ä¾åè½è· var
å¾ç¸ä¼¼ã主è¦ä¸åçå°æ¹å¨æ¼ var
ä½ç¨ç¯åæ¯ãæ´åãfunctionï¼
function varTest() {
var x = 1;
{
var x = 2; // é裡ç x è function åå¡å
§é¨ç x æ¯ä¸æ¨£çï¼å æ¤æå½±é¿ function åå¡å
§ææç x
console.log(x); // 2
}
console.log(x); // 2
}
function letTest() {
let x = 1;
{
let x = 2; // é裡ç x è function åå¡å
§é¨ç x æ¯ä¸åçï¼åªæä½ç¨å¨é層 block åå¡ä¸
console.log(x); // 2
}
console.log(x); // 1
}
å¨ä¸åä¾å裡çæåè¡ let
å var
ä¸åï¼let
䏦䏿å¨å
¨åç©ä»¶ä¸å»ºç«è®æ¸ãèä¾ä¾èªªï¼
var x = "global";
let y = "global";
console.log(this.x); // "global"
console.log(this.y); // undefined
Emulating private members
In dealing with constructors it is possible to use the let
bindings to share one or more private members without using closures:
var Thing;
{
let privateScope = new WeakMap();
let counter = 0;
Thing = function () {
this.someProperty = "foo";
privateScope.set(this, {
hidden: ++counter,
});
};
Thing.prototype.showPublic = function () {
return this.someProperty;
};
Thing.prototype.showPrivate = function () {
return privateScope.get(this).hidden;
};
}
console.log(typeof privateScope);
// "undefined"
var thing = new Thing();
console.log(thing);
// Thing {someProperty: "foo"}
thing.showPublic();
// "foo"
thing.showPrivate();
// 1
Temporal Dead Zone and errors with let
Redeclaring the same variable within the same function or block scope raises a SyntaxError
.
if (x) {
let foo;
let foo; // SyntaxError thrown.
}
In ECMAScript 2015, let
bindings are not subject to Variable Hoisting, which means that let
declarations do not move to the top of the current execution context. Referencing the variable in the block before the initialization results in a ReferenceError
(contrary to a variable declared with var, which will just have the undefined value). The variable is in a "temporal dead zone" from the start of the block until the initialization is processed.
function do_something() {
console.log(foo); // ReferenceError
let foo = 2;
}
ä½ å¯è½æå¨ switch
ä¸éå°é¯èª¤ï¼å çºææç case
é½å±¬æ¼å樣çåå¡ä¸ã
switch (x) {
case 0:
let foo;
break;
case 1:
let foo; // SyntaxError for redeclaration.
break;
}
let
æ¼ for
è¿´åç宣åç¯å
You can use the let
keyword to bind variables locally in the scope of for
loops. This is different from the var keyword in the head of a for loop, which makes the variables visible in the whole function containing the loop.
var i = 0;
for (let i = i; i < 10; i++) {
console.log(i);
}
However, it's important to point out that a block nested inside a case clause will create a new block scoped lexical environment, which will not produce the redeclaration errors shown above.
let x = 1;
switch (x) {
case 0: {
let foo;
break;
}
case 1: {
let foo;
break;
}
}
The temporal dead zone and typeof
Unlike with simply undeclared variables and variables that hold a value of undefined
, using the typeof
operator to check for the type of a variable in that variable's TDZ will throw a ReferenceError
:
// prints out 'undefined'
console.log(typeof undeclaredVariable);
// results in a 'ReferenceError'
console.log(typeof i);
let i = 10;
Another example of temporal dead zone combined with lexical scoping
Due to lexical scoping, the identifier "foo" inside the expression (foo + 55)
evaluates to the if block's foo, and not the overlying variable foo with the value of 33. In that very line, the if block's "foo" has already been created in the lexical environment, but has not yet reached (and terminated) its initialization (which is part of the statement itself): it's still in the temporal dead zone.
function test() {
var foo = 33;
{
let foo = foo + 55; // ReferenceError
}
}
test();
This phenomenon may confuse you in a situation like the following. The instruction let n of n.a
is already inside the private scope of the for loop's block, hence the identifier "n.a" is resolved to the property 'a' of the 'n' object located in the first part of the instruction itself ("let n"), which is still in the temporal dead zone since its declaration statement has not been reached and terminated.
function go(n) {
// n here is defined!
console.log(n); // Object {a: [1,2,3]}
for (let n of n.a) {
// ReferenceError
console.log(n);
}
}
go({ a: [1, 2, 3] });
Other situations
When used inside a block, let
limits the variable's scope to that block. Note the difference between var
whose scope is inside the function where it is declared.
var a = 1;
var b = 2;
if (a === 1) {
var a = 11; // the scope is global
let b = 22; // the scope is inside the if-block
console.log(a); // 11
console.log(b); // 22
}
console.log(a); // 11
console.log(b); // 2
è¦ç¯ ç覽å¨ç¸å®¹æ§ åè¦
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4