This question already has answers here:
What are the precise semantics of block-level functions in ES6?
(2 answers)
Closed 7 years ago.
What is block scope function in ECMAScript 6?
Can anyone help me understand the main difference in the block scope function compared to ECMAScript 5?
The new let and const in ES2015 (aka "ES6") have four major differences compared with the venerable var:
They have block scope
They aren't hoisted (well, they're sort of hoisted, but in a useful way)
Repeated declarations are errors
When used at global scope, they don't create properties of the global object (despite creating global variables; this is a new concept as of ES2015)
(For what it's worth, this is covered in detail in Chapter 2 of my recent book JavaScript: The New Toys, which covers ES2015-ES2020.)
Block scope
var variables exist throughout the function they're declared in (or globally, if declared globally), they aren't confined to the block they're in. So this code is valid:
function foo(flag) {
a = 10;
if (flag) {
var a = 20;
}
return a;
}
console.log(foo(false)); // 10
console.log(foo(true)); // 20
a is defined regardless of whether flag is true and it exists outside the if block; all three as above are the same variable.
That's not true of let (or const):
function foo(flag) {
if (flag) {
let a = 10;
}
return a; // ReferenceError: a is not defined
}
console.log(foo(true));
a only exists inside the block it's declared in. (For for statements, a declaration within the () of the for is handled very specially: a new variable is declared within the block for each loop iteration.) So outside the if, a doesn't exist.
let and const declarations can shadow declarations in an enclosing scope, e.g.:
function foo() {
let a = "outer";
for (let a = 0; a < 3; ++a) {
console.log(a);
}
console.log(a);
}
foo();
That outputs
0
1
2
outer
...because the a outside the for loop isn't the same a as the one inside the for loop.
Hoisting
This is valid code:
function foo() {
a = 5;
var a = a * 2;
return a;
}
Bizarre-looking, but valid (it returns 10), because var is done before anything else is done in the function, so that's really:
function foo() {
var a; // <== Hoisted
a = 5;
a = a * 2; // <== Left where it is
return a;
}
That's not true of let or const:
function foo() {
a = 5; // <== ReferenceError: a is not defined
let a = a * 2;
return a;
}
You can't use the variable until its declaration. The declaration isn't "hoisted" (well, it's partially hoisted, keep reading).
Earlier I said
They aren't hoisted (well, they're sort of hoisted, but in a useful way)
"Sort of"? Yes. A let or const declaration shadows an identifier throughout the block in which it appears, even though it only actually takes effect where it occurs. Examples help:
function foo() {
let a = "outer";
for (let x = 0; x < 3; ++x) {
console.log(a); // ReferenceError: a is not defined
let a = 27;
}
}
Note that instead of getting "outer" in the console, we get an error. Why? Because the let a in the for block shadows the a outside the block even though we haven't gotten to it yet. The space between the beginning of the block and the let is called the "temporal dead zone" by the spec. Words aren't everybody's thing, so here's a diagram:
Repeated declarations
This is valid code:
function foo() {
var a;
// ...many lines later...
var a;
}
The second var is simply ignored.
That's not true of let (or const):
function foo() {
let a;
// ...many lines later...
let a; // <== SyntaxError: Identifier 'a' has already been declared
}
Globals that aren't properties of the global object
JavaScript has the concept of a "global object" which holds various global things as properties. In loose mode, this at global scope refers to the global object, and on browsers there's a global that refers to the global object: window. (Some other environments provide a different global, such as global on NodeJS.)
Until ES2015, all global variables in JavaScript were properties of the global object. As of ES2015, that's still true of ones declared with var, but not ones declared with let or const. So this code using var at global scope, on a browser, displays 42:
"use strict";
var a = 42; // Global variable called "a"
console.log(window.a); // Shows 42, because a is a property of the global object
But this code shows undefined for the properties, because let and const at global scope don't create properties on the global object:
"use strict";
let a = 42; // Global variable called "a"
console.log(a); // 42 (of course)
console.log(window.a); // undefined, there is no "a" property on the global object
const q = "Life, the Universe, and Everything"; // Global constant
console.log(q); // "Life, the Universe, and Everything" (of course)
console.log(window.q); // undefined, there is no "q" property on the global object
Final note: Much of the above also holds true if you compare the new ES2015 class (which provides a new, cleaner syntax for creating constructor functions and the prototype objects associated with them) with function declarations (as opposed to function expressions):
class declarations have block scope. In contrast, using a function declaration within a flow-control block is invalid. (It should be a syntax error; instead, different JavaScript engines handle it differently. Some relocate it outside the flow-control block, others act as though you'd used a function expression instead.)
class declarations aren't hoisted; function declarations are.
Using the same name with two class declarations in the same scope is a syntax error; with a function declaration, the second one wins, overwriting the first.
class declarations at global scope don't create properties of the global object; function declarations do.
Just as a reminder, this is a function declaration:
function Foo() {
}
These are both function expressions (anonymous ones):
var Foo = function() {
};
doSomething(function() { /* ... */ });
These are both function expressions (named ones):
var Foo = function Foo() {
};
doSomething(function Foo() { /* ... */ });
Related
I have been playing with ES6 for a while and I noticed that while variables declared with var are hoisted as expected...
console.log(typeof name); // undefined
var name = "John";
...variables declared with let or const seem to have some problems with hoisting:
console.log(typeof name); // ReferenceError
let name = "John";
and
console.log(typeof name); // ReferenceError
const name = "John";
Does this mean that variables declared with let or const are not hoisted? What is really going on here? Is there any difference between let and const in this matter?
#thefourtheye is correct in saying that these variables cannot be accessed before they are declared. However, it's a bit more complicated than that.
Are variables declared with let or const not hoisted? What is really going on here?
All declarations (var, let, const, function, function*, class) are "hoisted" in JavaScript. This means that if a name is declared in a scope, in that scope the identifier will always reference that particular variable:
x = "global";
// function scope:
(function() {
x; // not "global"
var/let/… x;
}());
// block scope (not for `var`s):
{
x; // not "global"
let/const/… x;
}
This is true both for function and block scopes1.
The difference between var/function/function* declarations and let/const/class declarations is the initialisation.
The former are initialised with undefined or the (generator) function right when the binding is created at the top of the scope. The lexically declared variables however stay uninitialised. This means that a ReferenceError exception is thrown when you try to access it. It will only get initialised when the let/const/class statement is evaluated, everything before (above) that is called the temporal dead zone.
x = y = "global";
(function() {
x; // undefined
y; // Reference error: y is not defined
var x = "local";
let y = "local";
}());
Notice that a let y; statement initialises the variable with undefined like let y = undefined; would have.
The temporal dead zone is not a syntactic location, but rather the time between the variable (scope) creation and the initialisation. It's not an error to reference the variable in code above the declaration as long as that code is not executed (e.g. a function body or simply dead code), and it will throw an exception if you access the variable before the initialisation even if the accessing code is below the declaration (e.g. in a hoisted function declaration that is called too early).
Is there any difference between let and const in this matter?
No, they work the same as far as hoisting is regarded. The only difference between them is that a constant must be and can only be assigned in the initialiser part of the declaration (const one = 1;, both const one; and later reassignments like one = 2 are invalid).
1: var declarations are still working only on the function level, of course
Quoting ECMAScript 6 (ECMAScript 2015) specification's, let and const declarations section,
The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated.
So, to answer your question, yes, let and const hoist but you cannot access them before the actual declaration is evaluated at runtime.
ES6 introduces Let variables which comes up with block level scoping. Until ES5 we did not have block level scoping, so the variables which are declared inside a block are always hoisted to function level scoping.
Basically Scope refers to where in your program your variables are visible, which determines where you are allowed to use variables you have declared. In ES5 we have global scope,function scope and try/catch scope, with ES6 we also get the block level scoping by using Let.
When you define a variable with var keyword, it's known the entire function from the moment it's defined.
When you define a variable with let statement it's only known in the block it's defined.
function doSomething(arr){
//i is known here but undefined
//j is not known here
console.log(i);
console.log(j);
for(var i=0; i<arr.length; i++){
//i is known here
}
//i is known here
//j is not known here
console.log(i);
console.log(j);
for(let j=0; j<arr.length; j++){
//j is known here
}
//i is known here
//j is not known here
console.log(i);
console.log(j);
}
doSomething(["Thalaivar", "Vinoth", "Kabali", "Dinesh"]);
If you run the code, you could see the variable j is only known in the loop and not before and after. Yet, our variable i is known in the entire function from the moment it is defined onward.
There is another great advantage using let as it creates a new lexical environment and also binds fresh value rather than keeping an old reference.
for(var i=1; i<6; i++){
setTimeout(function(){
console.log(i);
},1000)
}
for(let i=1; i<6; i++){
setTimeout(function(){
console.log(i);
},1000)
}
The first for loop always print the last value, with let it creates a new scope and bind fresh values printing us 1, 2, 3, 4, 5.
Coming to constants, it work basically like let, the only difference is their value can't be changed. In constants mutation is allowed but reassignment is not allowed.
const foo = {};
foo.bar = 42;
console.log(foo.bar); //works
const name = []
name.push("Vinoth");
console.log(name); //works
const age = 100;
age = 20; //Throws Uncaught TypeError: Assignment to constant variable.
console.log(age);
If a constant refers to an object, it will always refer to the object but the object itself can be changed (if it is mutable). If you like to have an immutable object, you could use Object.freeze([])
As per ECMAScript® 2021
Let and Const Declarations
let and const declarations define variables that are scoped to the running execution context's LexicalEnvironment.
The variables are created when their containing Environment Record is instantiated but may not be accessed in any way until the variable's LexicalBinding is evaluated.
A variable defined by a LexicalBinding with an Initializer is assigned the value of its Initializer's AssignmentExpression when the LexicalBinding is evaluated, not when the variable is created.
If a LexicalBinding in a let declaration does not have an Initializer the variable is assigned the value undefined when the LexicalBinding is evaluated.
Block Declaration Instantiation
When a Block or CaseBlock is evaluated a new declarative Environment Record is created and bindings for each block scoped variable, constant, function, or class declared in the block are instantiated in the Environment Record.
No matter how control leaves the Block the LexicalEnvironment is always restored to its former state.
Top Level Lexically Declared Names
At the top level of a function, or script, function declarations are treated like var declarations rather than like lexical declarations.
Conclusion
let and const are hoisted but not initialized.
Referencing the variable in the block before the variable declaration results in a ReferenceError, because the variable is in a "temporal dead zone" from the start of the block until the declaration is processed.
Examples below make it clear as to how "let" variables behave in a lexical scope/nested-lexical scope.
Example 1
var a;
console.log(a); //undefined
console.log(b); //undefined
var b;
let x;
console.log(x); //undefined
console.log(y); // Uncaught ReferenceError: y is not defined
let y;
The variable 'y' gives a referenceError, that doesn't mean it's not hoisted. The variable is created when the containing environment is instantiated. But it may not be accessed bcz of it being in an inaccessible "temporal dead zone".
Example 2
let mylet = 'my value';
(function() {
//let mylet;
console.log(mylet); // "my value"
mylet = 'local value';
})();
Example 3
let mylet = 'my value';
(function() {
let mylet;
console.log(mylet); // undefined
mylet = 'local value';
})();
In Example 3, the freshly declared "mylet" variable inside the function does not have an Initializer before the log statement, hence the value "undefined".
Source
ECMA
MDN
From MDN web docs:
In ECMAScript 2015, let and const are hoisted but not initialized. Referencing the variable in the block before the variable declaration results in a ReferenceError because the variable is in a "temporal dead zone" from the start of the block until the declaration is processed.
console.log(x); // ReferenceError
let x = 3;
in es6 when we use let or const we have to declare the variable before using them.
eg. 1 -
// this will work
u = 10;
var u;
// this will give an error
k = 10;
let k; // ReferenceError: Cannot access 'k' before initialization.
eg. 2-
// this code works as variable j is declared before it is used.
function doSmth() {
j = 9;
}
let j;
doSmth();
console.log(j); // 9
let and const are also hoisted.
But an exception will be thrown if a variable declared with let or const is read before it is initialised due to below reasons.
Unlike var, they are not initialised with a default value while hoisting.
They cannot be read/written until they have been fully initialised.
I have been playing with ES6 for a while and I noticed that while variables declared with var are hoisted as expected...
console.log(typeof name); // undefined
var name = "John";
...variables declared with let or const seem to have some problems with hoisting:
console.log(typeof name); // ReferenceError
let name = "John";
and
console.log(typeof name); // ReferenceError
const name = "John";
Does this mean that variables declared with let or const are not hoisted? What is really going on here? Is there any difference between let and const in this matter?
#thefourtheye is correct in saying that these variables cannot be accessed before they are declared. However, it's a bit more complicated than that.
Are variables declared with let or const not hoisted? What is really going on here?
All declarations (var, let, const, function, function*, class) are "hoisted" in JavaScript. This means that if a name is declared in a scope, in that scope the identifier will always reference that particular variable:
x = "global";
// function scope:
(function() {
x; // not "global"
var/let/… x;
}());
// block scope (not for `var`s):
{
x; // not "global"
let/const/… x;
}
This is true both for function and block scopes1.
The difference between var/function/function* declarations and let/const/class declarations is the initialisation.
The former are initialised with undefined or the (generator) function right when the binding is created at the top of the scope. The lexically declared variables however stay uninitialised. This means that a ReferenceError exception is thrown when you try to access it. It will only get initialised when the let/const/class statement is evaluated, everything before (above) that is called the temporal dead zone.
x = y = "global";
(function() {
x; // undefined
y; // Reference error: y is not defined
var x = "local";
let y = "local";
}());
Notice that a let y; statement initialises the variable with undefined like let y = undefined; would have.
The temporal dead zone is not a syntactic location, but rather the time between the variable (scope) creation and the initialisation. It's not an error to reference the variable in code above the declaration as long as that code is not executed (e.g. a function body or simply dead code), and it will throw an exception if you access the variable before the initialisation even if the accessing code is below the declaration (e.g. in a hoisted function declaration that is called too early).
Is there any difference between let and const in this matter?
No, they work the same as far as hoisting is regarded. The only difference between them is that a constant must be and can only be assigned in the initialiser part of the declaration (const one = 1;, both const one; and later reassignments like one = 2 are invalid).
1: var declarations are still working only on the function level, of course
Quoting ECMAScript 6 (ECMAScript 2015) specification's, let and const declarations section,
The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated.
So, to answer your question, yes, let and const hoist but you cannot access them before the actual declaration is evaluated at runtime.
ES6 introduces Let variables which comes up with block level scoping. Until ES5 we did not have block level scoping, so the variables which are declared inside a block are always hoisted to function level scoping.
Basically Scope refers to where in your program your variables are visible, which determines where you are allowed to use variables you have declared. In ES5 we have global scope,function scope and try/catch scope, with ES6 we also get the block level scoping by using Let.
When you define a variable with var keyword, it's known the entire function from the moment it's defined.
When you define a variable with let statement it's only known in the block it's defined.
function doSomething(arr){
//i is known here but undefined
//j is not known here
console.log(i);
console.log(j);
for(var i=0; i<arr.length; i++){
//i is known here
}
//i is known here
//j is not known here
console.log(i);
console.log(j);
for(let j=0; j<arr.length; j++){
//j is known here
}
//i is known here
//j is not known here
console.log(i);
console.log(j);
}
doSomething(["Thalaivar", "Vinoth", "Kabali", "Dinesh"]);
If you run the code, you could see the variable j is only known in the loop and not before and after. Yet, our variable i is known in the entire function from the moment it is defined onward.
There is another great advantage using let as it creates a new lexical environment and also binds fresh value rather than keeping an old reference.
for(var i=1; i<6; i++){
setTimeout(function(){
console.log(i);
},1000)
}
for(let i=1; i<6; i++){
setTimeout(function(){
console.log(i);
},1000)
}
The first for loop always print the last value, with let it creates a new scope and bind fresh values printing us 1, 2, 3, 4, 5.
Coming to constants, it work basically like let, the only difference is their value can't be changed. In constants mutation is allowed but reassignment is not allowed.
const foo = {};
foo.bar = 42;
console.log(foo.bar); //works
const name = []
name.push("Vinoth");
console.log(name); //works
const age = 100;
age = 20; //Throws Uncaught TypeError: Assignment to constant variable.
console.log(age);
If a constant refers to an object, it will always refer to the object but the object itself can be changed (if it is mutable). If you like to have an immutable object, you could use Object.freeze([])
As per ECMAScript® 2021
Let and Const Declarations
let and const declarations define variables that are scoped to the running execution context's LexicalEnvironment.
The variables are created when their containing Environment Record is instantiated but may not be accessed in any way until the variable's LexicalBinding is evaluated.
A variable defined by a LexicalBinding with an Initializer is assigned the value of its Initializer's AssignmentExpression when the LexicalBinding is evaluated, not when the variable is created.
If a LexicalBinding in a let declaration does not have an Initializer the variable is assigned the value undefined when the LexicalBinding is evaluated.
Block Declaration Instantiation
When a Block or CaseBlock is evaluated a new declarative Environment Record is created and bindings for each block scoped variable, constant, function, or class declared in the block are instantiated in the Environment Record.
No matter how control leaves the Block the LexicalEnvironment is always restored to its former state.
Top Level Lexically Declared Names
At the top level of a function, or script, function declarations are treated like var declarations rather than like lexical declarations.
Conclusion
let and const are hoisted but not initialized.
Referencing the variable in the block before the variable declaration results in a ReferenceError, because the variable is in a "temporal dead zone" from the start of the block until the declaration is processed.
Examples below make it clear as to how "let" variables behave in a lexical scope/nested-lexical scope.
Example 1
var a;
console.log(a); //undefined
console.log(b); //undefined
var b;
let x;
console.log(x); //undefined
console.log(y); // Uncaught ReferenceError: y is not defined
let y;
The variable 'y' gives a referenceError, that doesn't mean it's not hoisted. The variable is created when the containing environment is instantiated. But it may not be accessed bcz of it being in an inaccessible "temporal dead zone".
Example 2
let mylet = 'my value';
(function() {
//let mylet;
console.log(mylet); // "my value"
mylet = 'local value';
})();
Example 3
let mylet = 'my value';
(function() {
let mylet;
console.log(mylet); // undefined
mylet = 'local value';
})();
In Example 3, the freshly declared "mylet" variable inside the function does not have an Initializer before the log statement, hence the value "undefined".
Source
ECMA
MDN
From MDN web docs:
In ECMAScript 2015, let and const are hoisted but not initialized. Referencing the variable in the block before the variable declaration results in a ReferenceError because the variable is in a "temporal dead zone" from the start of the block until the declaration is processed.
console.log(x); // ReferenceError
let x = 3;
in es6 when we use let or const we have to declare the variable before using them.
eg. 1 -
// this will work
u = 10;
var u;
// this will give an error
k = 10;
let k; // ReferenceError: Cannot access 'k' before initialization.
eg. 2-
// this code works as variable j is declared before it is used.
function doSmth() {
j = 9;
}
let j;
doSmth();
console.log(j); // 9
let and const are also hoisted.
But an exception will be thrown if a variable declared with let or const is read before it is initialised due to below reasons.
Unlike var, they are not initialised with a default value while hoisting.
They cannot be read/written until they have been fully initialised.
I have been playing with ES6 for a while and I noticed that while variables declared with var are hoisted as expected...
console.log(typeof name); // undefined
var name = "John";
...variables declared with let or const seem to have some problems with hoisting:
console.log(typeof name); // ReferenceError
let name = "John";
and
console.log(typeof name); // ReferenceError
const name = "John";
Does this mean that variables declared with let or const are not hoisted? What is really going on here? Is there any difference between let and const in this matter?
#thefourtheye is correct in saying that these variables cannot be accessed before they are declared. However, it's a bit more complicated than that.
Are variables declared with let or const not hoisted? What is really going on here?
All declarations (var, let, const, function, function*, class) are "hoisted" in JavaScript. This means that if a name is declared in a scope, in that scope the identifier will always reference that particular variable:
x = "global";
// function scope:
(function() {
x; // not "global"
var/let/… x;
}());
// block scope (not for `var`s):
{
x; // not "global"
let/const/… x;
}
This is true both for function and block scopes1.
The difference between var/function/function* declarations and let/const/class declarations is the initialisation.
The former are initialised with undefined or the (generator) function right when the binding is created at the top of the scope. The lexically declared variables however stay uninitialised. This means that a ReferenceError exception is thrown when you try to access it. It will only get initialised when the let/const/class statement is evaluated, everything before (above) that is called the temporal dead zone.
x = y = "global";
(function() {
x; // undefined
y; // Reference error: y is not defined
var x = "local";
let y = "local";
}());
Notice that a let y; statement initialises the variable with undefined like let y = undefined; would have.
The temporal dead zone is not a syntactic location, but rather the time between the variable (scope) creation and the initialisation. It's not an error to reference the variable in code above the declaration as long as that code is not executed (e.g. a function body or simply dead code), and it will throw an exception if you access the variable before the initialisation even if the accessing code is below the declaration (e.g. in a hoisted function declaration that is called too early).
Is there any difference between let and const in this matter?
No, they work the same as far as hoisting is regarded. The only difference between them is that a constant must be and can only be assigned in the initialiser part of the declaration (const one = 1;, both const one; and later reassignments like one = 2 are invalid).
1: var declarations are still working only on the function level, of course
Quoting ECMAScript 6 (ECMAScript 2015) specification's, let and const declarations section,
The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated.
So, to answer your question, yes, let and const hoist but you cannot access them before the actual declaration is evaluated at runtime.
ES6 introduces Let variables which comes up with block level scoping. Until ES5 we did not have block level scoping, so the variables which are declared inside a block are always hoisted to function level scoping.
Basically Scope refers to where in your program your variables are visible, which determines where you are allowed to use variables you have declared. In ES5 we have global scope,function scope and try/catch scope, with ES6 we also get the block level scoping by using Let.
When you define a variable with var keyword, it's known the entire function from the moment it's defined.
When you define a variable with let statement it's only known in the block it's defined.
function doSomething(arr){
//i is known here but undefined
//j is not known here
console.log(i);
console.log(j);
for(var i=0; i<arr.length; i++){
//i is known here
}
//i is known here
//j is not known here
console.log(i);
console.log(j);
for(let j=0; j<arr.length; j++){
//j is known here
}
//i is known here
//j is not known here
console.log(i);
console.log(j);
}
doSomething(["Thalaivar", "Vinoth", "Kabali", "Dinesh"]);
If you run the code, you could see the variable j is only known in the loop and not before and after. Yet, our variable i is known in the entire function from the moment it is defined onward.
There is another great advantage using let as it creates a new lexical environment and also binds fresh value rather than keeping an old reference.
for(var i=1; i<6; i++){
setTimeout(function(){
console.log(i);
},1000)
}
for(let i=1; i<6; i++){
setTimeout(function(){
console.log(i);
},1000)
}
The first for loop always print the last value, with let it creates a new scope and bind fresh values printing us 1, 2, 3, 4, 5.
Coming to constants, it work basically like let, the only difference is their value can't be changed. In constants mutation is allowed but reassignment is not allowed.
const foo = {};
foo.bar = 42;
console.log(foo.bar); //works
const name = []
name.push("Vinoth");
console.log(name); //works
const age = 100;
age = 20; //Throws Uncaught TypeError: Assignment to constant variable.
console.log(age);
If a constant refers to an object, it will always refer to the object but the object itself can be changed (if it is mutable). If you like to have an immutable object, you could use Object.freeze([])
As per ECMAScript® 2021
Let and Const Declarations
let and const declarations define variables that are scoped to the running execution context's LexicalEnvironment.
The variables are created when their containing Environment Record is instantiated but may not be accessed in any way until the variable's LexicalBinding is evaluated.
A variable defined by a LexicalBinding with an Initializer is assigned the value of its Initializer's AssignmentExpression when the LexicalBinding is evaluated, not when the variable is created.
If a LexicalBinding in a let declaration does not have an Initializer the variable is assigned the value undefined when the LexicalBinding is evaluated.
Block Declaration Instantiation
When a Block or CaseBlock is evaluated a new declarative Environment Record is created and bindings for each block scoped variable, constant, function, or class declared in the block are instantiated in the Environment Record.
No matter how control leaves the Block the LexicalEnvironment is always restored to its former state.
Top Level Lexically Declared Names
At the top level of a function, or script, function declarations are treated like var declarations rather than like lexical declarations.
Conclusion
let and const are hoisted but not initialized.
Referencing the variable in the block before the variable declaration results in a ReferenceError, because the variable is in a "temporal dead zone" from the start of the block until the declaration is processed.
Examples below make it clear as to how "let" variables behave in a lexical scope/nested-lexical scope.
Example 1
var a;
console.log(a); //undefined
console.log(b); //undefined
var b;
let x;
console.log(x); //undefined
console.log(y); // Uncaught ReferenceError: y is not defined
let y;
The variable 'y' gives a referenceError, that doesn't mean it's not hoisted. The variable is created when the containing environment is instantiated. But it may not be accessed bcz of it being in an inaccessible "temporal dead zone".
Example 2
let mylet = 'my value';
(function() {
//let mylet;
console.log(mylet); // "my value"
mylet = 'local value';
})();
Example 3
let mylet = 'my value';
(function() {
let mylet;
console.log(mylet); // undefined
mylet = 'local value';
})();
In Example 3, the freshly declared "mylet" variable inside the function does not have an Initializer before the log statement, hence the value "undefined".
Source
ECMA
MDN
From MDN web docs:
In ECMAScript 2015, let and const are hoisted but not initialized. Referencing the variable in the block before the variable declaration results in a ReferenceError because the variable is in a "temporal dead zone" from the start of the block until the declaration is processed.
console.log(x); // ReferenceError
let x = 3;
in es6 when we use let or const we have to declare the variable before using them.
eg. 1 -
// this will work
u = 10;
var u;
// this will give an error
k = 10;
let k; // ReferenceError: Cannot access 'k' before initialization.
eg. 2-
// this code works as variable j is declared before it is used.
function doSmth() {
j = 9;
}
let j;
doSmth();
console.log(j); // 9
let and const are also hoisted.
But an exception will be thrown if a variable declared with let or const is read before it is initialised due to below reasons.
Unlike var, they are not initialised with a default value while hoisting.
They cannot be read/written until they have been fully initialised.
This question already has answers here:
What is the purpose of the var keyword and when should I use it (or omit it)?
(19 answers)
Closed 5 years ago.
I know basics about local and global variables, but could anybody explain difference between these two examples of code?
var elements = document.querySelectorAll('.classname');
for (var i = 0; i < elements.length; i++) {
// do something
}
and
var elements = document.querySelectorAll('.classname');
for (i = 0; i < elements.length; i++) { // <-- removed "var" before "i = 0"
// do something
}
With the var keyword, there is no "block" scope, so declarations are either "function" scoped or "global". The fact that you declare a variable in a loop or in a true/false branch of an if statement does not create a variable scoped to just that block of code. This is quite different than in most compiled languages.
ECMAScript 2016 (a.k.a. ES6) introduces "block" scope with the let keyword.
So, if you omit the var keyword and just create a new variable in a function, that variable becomes global because the JS runtime doesn't know where you wanted it scoped to.
Here's some examples:
// Outside of functions, the var keyword creates global variables
var g = "global";
function foo(){
// Inside of functions, the var keyword creates "local" or function scoped variables
var l = "local";
// But, omitting the "var" keyword, whereever you do it, creates a global
oops = "global";
// But, creating a function scoped variable of the same name as a variable in a higher
// scope, just hides the one from the higer scope as long as the code runs in the smaller
// scope:
var g = "local";
// Other than global and function, the var keyword does not create "block" scope:
if(true){
var x = "surprise!";
}
// Now, we'll see what we get when we are in the local scope:
console.log(g); // "local", not "global" because smaller scope prevails
console.log(l); // "local";
console.log(oops); // "global"
console.log(x); // "surprise!" because x has function scope, not block
}
foo();
// Now, we'll see what is available back in the global scope:
console.log(g); // "global" because now we are in the global scope
console.log(typeof l); // It's an error to try to access directly, type is undefined
console.log(oops); // "global" because we omitted var and it became global
console.log(typeof x); // It's an error to try to access directly, type is undefined
Consider three cases, where both a and k are undefined:
if (a) console.log(1); // ReferenceError
and
var a = k || "value"; // ReferenceError
seems reasonable, but...
var a = a || "value"; // "value"
Why doesn't the last case throw a ReferenceError? Isn't a being referenced before it's defined?
This is because of one of var's "features" called hoisting. Per the link:
Because variable declarations (and declarations in general) are processed before any code is executed, declaring a variable anywhere in the code is equivalent to declaring it at the top. This also means that a variable can appear to be used before it's declared. This behavior is called "hoisting", as it appears that the variable declaration is moved to the top of the function or global code. (emphasis mine)
So, for example:
console.log(a);
var a = "foo";
Instead of throwing a ReferenceError as you might expect, since a is referenced before it is defined, it logs undefined. This is because, as mentioned earlier, the declaration is processed first and essentially happens at the top, which means it's the same as:
var a;
console.log(a);
a = "foo";
The same goes for functions as mentioned earlier:
function foo() {
console.log(a);
var a = "foo";
}
That's the same as:
function foo() {
var a;
console.log(a);
a = "foo";
}
To see why, look into the ECMAScript 2015 Language Specification:
13.3.2 Variable Statement
NOTE
A var statement declares variables that are scoped to the running execution context’s VariableEnvironment. Var variables are created when their containing Lexical Environment is instantiated and are initialized to undefined when created.
[...]
A variable defined by a VariableDeclaration with an Initializer is assigned the value of its Initializer’s AssignmentExpression when the VariableDeclaration is executed, not when the variable is created. (emphasis mine)
From this, we can gather that the var declarations are created before any code is executed (in their lexical environment) and are scoped to the containing VariableEnvironment, which is either in the global scope, or in a function. They are initially given the value undefined. The next part explains that the value that the var is assigned to is the value of the right hand side when the declaration is executed, not when the variable is created.
This applies to your situation because in your example, a is referenced like it is in the example. Using the information earlier, your code:
var a = a || "value";
Can be rewritten as:
var a;
a = a || "value";
Remember that all declarations are processed before any code is executed. The JavaScript engine sees that there's a declaration, variable a and declares it at the top of the current function or global scope. It is then given the value undefined. Since undefined is falsey, a is assigned to value.
In contrast, your second example throws a ReferenceError:
var a = k || "value";
It can also be rewritten as:
var a;
a = k || "value";
Now you see the problem. Since k is never a declared anywhere, no variable with that identifier exists. That means, unlike with a in the first example, k is never declared and throws the ReferenceError because it is referenced before declaration.
But how do you explain var a = "123"; var a = a || "124"; // a = "123"?
From the ES2015 Language Specification again:
Within the scope of any VariableEnvironment a common BindingIdentifier may appear in more than one VariableDeclaration but those declarations collective define only one variable.
To put it plainly: variables can be defined in the same function or global scope more than once, but always define the same variable. Thus, in your example:
var a = "123";
var a = a || "124";
It can be rewritten as:
var a;
a = "123";
a = a || "124";
Declaring a in the same function or global scope again collectively only declares it once. a is assigned to "123", then it is assigned to "123" again because "123" is truthy.
As of ES2015, you should, in my opinion, no longer use var. It has function scoping and can cause unexpected assignments like those mentioned in the question. Instead, if you still want mutability, try using let:
let a = a || "value";
This will throw a ReferenceError. Even though all variables are hoisted, no matter which declarator you use (var, let, or const), with let and const it is invalid to reference an uninitialized variable. Also, let and const have block scope, not function scope. This is more clear and normal regarding other languages:
function foo() {
{
var a = 3;
}
console.log(a); //logs 3
}
Versus:
function foo() {
{
let a = 3;
}
console.log(a); //ReferenceError
}
var a = k || 'value';
var a = a || 'value';
a is declared when you call var a but k is not, that why first line is ReferenceError and second line is 'value'
if (a) console.log(1); // ReferenceError
in this case i think there is no doubt as a is not declared anywhere before using it so refrence error
var a = k || "value"; //ReferenceError
same case here k is not declared and we are trying to use it
var a = a || "value"; //"value"
now in this case when we are trying use a (a in r.h.s) that time a is already declared before using it and hence no error
Adding to this if you want to know difference between reference error and undefined
refrence error -indicate variable is not declared yet whereas
undefined - it is special value in javascript assigned to any variable as soon as it is declared undefined indicates that variable is declared but has not taken any value