Lexical scope you dont know js code#
Lexical scope is defined at author time, when the code is written. Above rules, only for first class identifiers, then follow by object property-access rules.Otherwise, Compiler will produce code that (at execution time) asks Scope Manager to create a new variable called students in that scope bucket.Ĭompiler then produces code for Engine to later execute, to handle the students = assignment. If so, Compiler would ignore this declaration and move on. Here's the steps Compiler will follow to handle that statement:Įncountering var students, Compiler will ask Scope Manager to see if a variable named students already exists for that particular scope bucket. A reasonable assumption would be that Compiler will produce code for the first statement such as: "Allocate memory for a variable, label it students, then stick a reference to the array into that variable." But that's not the whole story.
Once Compiler gets to code generation, there's more detail to consider than may be obvious. The first thing Compiler will do with this program is perform lexing to break it down into tokens, which it will then parse into a tree (AST). In fact, JS treats these as two distinct operations, one which Compiler will handle during compilation, and the other which Engine will handle during execution. We typically think of that as a single statement, but that's not how our friend Engine sees it. The array and its contents are just basic JS value literals (and thus unaffected by any scoping concerns), so our focus here will be on the var students = declaration and initialization-assignment parts. Let's examine how JS is going to process that program, specifically starting with the first statement.
outer/global scope: RED var students = [ var nextStudent = getStudentName ( 73 ) console. Let's annotate the running program example from Chapter 1 with scope color labels: The color of each marble is thus determined by which color scope we find the marble originally created in. The buckets are scopes (functions and blocks), which we just conceptually assign individual colors for our discussion purposes. In this metaphor, the marbles are the variables in our program. After sorting, when you later need a green marble, you already know the green bucket is where to go to get it. Let's sort all the marbles, dropping the red ones into a red bucket, green into a green bucket, and blue into a blue bucket.
Imagine you come across a pile of marbles, and notice that all the marbles are colored red, blue, or green. One metaphor I've found effective in understanding scope is sorting colored marbles into buckets of their matching color. The goal here is to think about how your program is handled by the JS engine in ways that more closely align with how the JS engine actually works. This chapter will illustrate scope with several metaphors. Like way back in grade school math class, getting the right answer isn't enough if we don't show the correct steps to get there! We need to build accurate and helpful mental models as foundation moving forward. If we rely on guesses and intuition, we may accidentally get the right answers some of the time, but many other times we're far off. To properly reason about our programs, it's important to have a solid conceptual foundation of how scope works.
In Chapter 1, we explored how scope is determined during code compilation, a model called "lexical scope." The term "lexical" refers to the first stage of compilation (lexing/parsing). You Don't Know JS Yet: Scope & Closures - 2nd Edition Chapter 2: Illustrating Lexical Scope