Javascript Foundation — Function Invocation, Arguments keyword, Variable environment, Scope chain.
Programs simply assign memory, for example, assigning a value to a variable, and then run a function to do something with the variable. It’s really all a program is. Without functions, our programs would do nothing.
So let's define functions and some of the common terms around them.
Function Declaration
A function Declaration starts with a function keyword. For example,
A function expression doesn't start with a function keyword.
We can call/invoke/execute a function.
This simply means that we are telling our Javascript engine to run our function. We have put the function in memory or assigned a variable, and now we can do something with our program.
We do a function invocation by simply running a function Canada() with two brackets. As soon as the Javascript engine sees these brackets, it’s going to create an execution context. We know this already from previous lessons.
But just to review, the Canada function is defined at runtime. When we call the function/execute the function, that's when we define what this function does. India, on the other hand, gets defined at parse time — when the compiler initially looks at the code and starts hoisting and allocating memory.
Arguments
When a function is invoked, we create a new execution context on top of our global execution context.
Unlike the Global execution context where our global object===this, with a function invocation we get something else called arguments — another keyword in Javascript.
If our assumptions are correct, if we run the above code we should have an argument object.
And indeed we do. The argument keyword gives us an object with the first key being Tim and the second key being Tina.
This means we don't get arguments in the global object. They are only available to us when we create a new execution context using a function.
Why arguments are dangerous to use.
Previously, we have talked about how we can help the javascript engine optimize our code. We also said that using arguments can be dangerous.
There are things you could do with the arguments keyword that might make the compiler less able to optimize your code. Arguments look like an array but it’s not really an array; you can't use array methods on it.
With the new Javascript, they introduced new tools we can use to avoid using arguments. There may be some cases when we wanna iterate or loop through arguments instead of just accessing them regularly.
One way to go about it is to use the new Array.from. We create an array from whatever we are given.
If we run this we get an array so that we can now use array methods on the arguments.
Rest Parameters
Another way to do this is to use Rest Parameters. It’s something we got with Es6 where we just use a spread operator instead of the two parameters.
And if we run the function we have args as our arguments.
With modern Javascript, you want to avoid using arguments. It was initially added to javascript and it caused a lot of problems and headaches. We can instead use the above techniques to convert that array-like object into an array so we can do helpful operations on it.
But what if inside our India() function we console.log the arguments?
We see that we get an empty arguments object. We can still use the arguments object even if it's empty even though we didn't pass any parameters. This is because, with each execution context, we create a new argument object.
Variable Environment
We’ve learned that there can be many execution contexts. But how about variables that are created inside of these individual execution contexts? The variables inside functions?
We have a place for that. On top of the execution context this & arguments, we have a little place called variable environment.
This is a place that variables can live in these different stack worlds. Yes, they all live in our javascript memory, but they need to know how they relate to one another. Some functions have access to certain variables and some don't.
You can think of execution context as each own planet — each own universe. These Worlds don't really communicate with each other or know of each other(for now at least).
So what do we have in a variable environment? Let's create two functions.
We see that we have variable declarations. So these get hoisted and put at the top allocating space for them. We also have isValid which is a global variable and is assigned undefined when it gets hoisted.
Here we start executing our code during the execution phase. The very first step is where we assign false to isValid. In the memory space, we change undefined to now false so that isValid=false.
The second step is where we run one(). We invoke the function and the new execution context is created on top of the stack.
So we go into the one() function where we have isValid that will be put into the new execution context. That is this variable will be put into the new local environment or the variable environment. We run function two();
So a new execution context is created. And on top of the stack, we add two. So now we go into the two() world. And in the two() world we have a new variable that is being declared. Initially, it's undefined. But then when we actually see this, nothing is being assigned to it so it remains undefined.
So let's think about this in terms of a variable environment. In the global environment, at the very bottom of the stack, we have the global execution context. where we have variable isValid =false.
So the global context will have false as its variable.
In the one() execution context, the local environment or variable environment is going to have a variable called isValid that is going to equal to true. It doesn't really care about what's happening in the global execution environment. It only cares about what's inside it for itself.
Inside two(), we already have isValid and it’s going to be undefined. So each of these worlds carries information or data that they have access to.
And so each execution context has its own variable environment.
Scope Chain
There is another piece to the puzzle. There is another part of the execution context that we haven't discussed.
Each execution context has a link to the outside world or a link to its parent. and this outer environment depends on where the function sits lexically — where the function is written.
If we created a new global function x, all these functions will have access to it. All functions have access to the global scope.
All these functions have a global lexical environment that is they are written in the global space on the main page, they just get attached to the window object.
So all these functions have their own variable environment, they have access to their own variables but they also have a scope chain and this chain gives us access to variables that are in our global environment.
With x it first looks in the variable environment and it only sees the variable c. When it doesn't find it, it goes up the scope chain to see if it's attached to the global environment. When it finds the x variable in the global environment, it's able to console.log(x).
This is called scope /static scope to be exact. What matters is where the function is written not where its called because of the variables.
The lexical scope means that by looking at the source code we can determine which environment the variables and data are available in. And that's what the compiler does. The Javascript compiler looks at the code and attaches all these scope chains before it runs the code.
Because we have lexical scope, we know what environments are linked to each other and we know what data can be accessed by which function. And the scope chain starts where the variable is defined and goes all the way down to the global context to see if the variable exists. Scope simply asks — Where can I access that variable? Where is that variable in my code?
>>>>>Function scope vs block scope
