- Global Execution Context (GEC)
- Function Execution Context (FEC)
Let’s take a detailed look at both.
Global Execution Context (GEC)
Function Execution Context (FEC)
Since each function call receives its own FEC, a script’s run-time may have many FECs.
|GLOBAL EXECUTION CONTEXT||FUNCTION EXECUTION CONTEXT|
|Creates an object called a Global Variable that houses declarations for functions and variables.||Does not provide an object for a global variable. Instead, it generates an object called an argument that contains every argument supplied to the function.|
|Creates the “this” object, which has methods and attributes for all the variables and functions in the global scope.||Not only has access to the environment’s “this” object but also doesn’t generate it. usually, the object in the “window”|
|Is unable to access the Function contexts defined in its code.||Having access to the code (variables and functions) in the context in which it is defined and that of its parents because of scope.|
|Creates memory space for functions and variables with global definitions.||Only allocates memory for the variables and functions that are defined within the function.|
Let’s look at how execution contexts are produced now that we are familiar with what they are and the many varieties that are available.
There are two steps involved in creating an execution context (GEC or FEC):
- Creation Phase
- Execution Phase
The Execution Context is first linked to an Execution Context Object during the construction process (ECO). The code in the execution context uses a large amount of crucial data that is stored in the execution context object during run-time.
The Execution Context Object’s properties are defined and set during the creation phase, which comprises three steps. These are the stages:
- The variable object’s creation (VO)
- Developing the Scope Chain
- Changing the “this” keyword’s value
The execution phase of an Execution Context follows the creation phase immediately. The actual code execution starts at this point.
The VO has variables with undefined values up until this point. We cannot operate with undefined values, so if the code is performed at this point, errors would undoubtedly result.
A specification object, “Lexical Environment,” only “theoretically” exists in the language specification to explain how things operate. We are unable to directly manipulate this object in our code.
The output of running this code is the same as it was when the “outer()” function was used in the preceding example above. What makes this function unique (and intriguing) is that it is returned from the outer function before being performed.
Inner and Outer Lexical Environment
The instance of “inner()” keeps track of the lexical context in which the variable name is present. Because of this, “Mozilla” is sent to console.log when “langName” is used, and the variable name is still usable.
Dynamic vs Lexical Scope
Lexical scoping is the process by which the variables that are available to you depend on where a function is defined. Dynamic scoping, on the other hand, uses the function’s invocation location to determine which variables are accessible.