The nature of THE JS scope: Before we talk about the nature of the JS scope, let’s talk about what a programming language does. What is the function of a programming language, to operate a computer, and how do you operate a computer? It’s a matter of getting the computer to do the calculations that we want it to do, and then getting the results; So what does computation calculate? Of course it’s data, so where is it stored? Of course it’s memory; Therefore, I understand the function of a programming language to be in two parts: 1. Accessing data (putting data into memory or reading it out of memory) 2. Instruct the computer to perform operations based on the data in memory

One of the scripting functions of a programming language is to access data, such as var a=10, which can be used to create a space in memory called a containing the number 10. Function test(){var a=100; a=1000; }; Var a=10; Is covered? Or are you reinventing the space for preservation? What if a is equal to 1000? Therefore, we needed a set of rules to manage access to variables, and the concept of scope was introduced

Scope: As the name suggests: Scope of a variable. Can be understood as one circle, rule is: circles can be seen outside the circle of data, data doesn’t have access to outside the circle area (unless provided corresponding exports Closure], for example, if the current circles had not found the target data, can search to the outer circle, until the global scope, if still not found, is an error

Function out(){var a=10; function inner1(){ console.log(a); } function inner2(){ var a=100; console.log(a); } inner1(); // output 10 inner2(); // output 100 console.log(r)} out();Copy the code

Of course, we can dynamically insert variables into the lexical scope by using the eval() function to change the lexical scope for example: function foo(str,a){ eval(str); console.log(a,b); } var b=10; Foo (‘ var b = 100; ‘, 1); // The first argument passed here changes the lexical scope interpretation: as we write, the lexical parser will assume that the b inside foo is pointing outward. But when the function is executed, the lexical scope is changed to point to a temporary definition of b=100, rendering the previous optimization meaningless. Therefore, try not to use the eval function

Function scope: based on function scope, nothing special, is the circle rule; Designed to not pollute the global scope, prevent naming conflicts, and hide implementation details (personal understanding). It is worth noting that when a variable is accessed inside a function, it is not found globally; For LHS (left query), variables are created globally; If it is RHS (right query), an error is reported. For example, var x=100; function test(x){ a=x; // create a variable a globally and assign the value of x to a; } test(x); The console. The log (Windows. A) / / output 100 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- the function test2 () {var m; m=t; T} test2(); Note: for left and right queries, very simple block-level scope: when we are using a loop structure, select the scope of the variable followed by curly braces or parentheses. When we are using loop structures, we want the curly braces to form a separate scope without contaminating the scope of the current structure, so we introduce block-level scopes for example: in the global scope we write for(var a=0; a<10; A ++){console.log(a) var b=100; } console.log(a)// output 10 console.log(b)// output 100 B. By doing so, you inadvertently pollute the global scope; So how do you do that? We can replace var with let to create block-level scope, and the variables defined by let will be in their own block-level scope, thus solving the pollution problem. for(let a=0; a<10; a++){ console.log(a); Let b=100; } console.log(a); / / error console. The log (b); / / an errorCopy the code

Special attention: there are wrong places, we point out, I will check, and then continue to cheat you, ha ha ha