├── JavaScript-A-Z-Notes-main
    └── Notes
    │   ├── 1-ExecutionContext.md
    │   ├── 10-Closures.md
    │   ├── 11-setTimeout-closures.md
    │   ├── 12-JSInterview-Closures.md
    │   ├── 14-Functions.md
    │   ├── 15-Callbacks-EventListeners.md
    │   ├── 16-Async-EventLoops.md
    │   ├── 17-JSEngine-ChromeV8.md
    │   ├── 17-setTimeout().md
    │   ├── 2-Execution-CallStack.md
    │   ├── 3-Hoisting.md
    │   ├── 4-Fun-VarEnv.md
    │   ├── 5-Window-this.md
    │   ├── 6-Undef-NotDef.md
    │   ├── 7-Scope-LexEnv.md
    │   ├── 8-letConst-deadzone-errors.md
    │   └── 9-BlockScope-Shadowing.md
├── README.md
└── javascript_notes.md


/JavaScript-A-Z-Notes-main/Notes/1-ExecutionContext.md:
--------------------------------------------------------------------------------
 1 | # Episode 1 : Execution Context
 2 | 
 3 | ### Everything in JS happens inside the execution context. 
 4 | 
 5 | Assume execution context to be a big box where everything takes place. It has 2 components in it:
 6 | <li> <strong>Memory : </strong>The place where all the variables and functions are stored as (key:value) pairs. Memory component is also known as <em>variable environment</em>.
 7 | <li> <strong>Code : </strong>The place where code is executed one line at a time. Code component is also known as <em>Thread of Execution</em>
 8 | 
 9 | ### JS is a synchronous single-threaded language. 
10 | <li> By single threaded, we mean JS can only run 1 command at a time
11 | <li> By synchronous single threaded, we mean it can run 1 command at a time, <em>in a specific order</em>
12 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/10-Closures.md:
--------------------------------------------------------------------------------
 1 | # Episode 10 : Closures in JS
 2 | 
 3 | ### Important Interview Question
 4 | 
 5 | **Closure :** Function bundled together with its lexical environment/scope.
 6 | 
 7 | ```
 8 | JS is a weird language. You can pass functions as parameters to another function, assign a variable to an entire function, or even return a function.
 9 | eg:
10 | 
11 | function x() {
12 |   var a = 7;
13 |   function y() {
14 |   console.log(a);
15 | }
16 |   return y;   // instead of y();
17 | }
18 | var z = x();
19 | console.log(z);  // value of z is entire code of function y.
20 | 
21 | ```
22 | 
23 | When functions are returned from another fun, they still maintain their lexical
24 | scope.
25 | 
26 | - When y is returned, not only is the fun returned but the entire closure (fun
27 |   y + its lexical scope) is returned and put inside z. So when z is used
28 |   somewhere else in program, it still remembers var a inside x()
29 | - Closure is a very powerful concept of JS, just because this function remembers
30 |   things even if they are not in their lexical scope
31 | 
32 | ### Uses of Closure
33 | 
34 | Module Design Pattern, Currying, Functions like once(fun that can be run only
35 | once), memoize, maintaining state in async world, setTimeout, iterators...
36 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/11-setTimeout-closures.md:
--------------------------------------------------------------------------------
 1 | # Episode 11 : setTimeout + Closures Interview Question 
 2 | 
 3 | #### Time, tide and Javascript wait for none
 4 | 
 5 | ```
 6 | function x() {
 7 |   var i = 1;
 8 |   setTimeout(function() {
 9 |   console.log(i);
10 |   }, 3000);
11 |   console.log("This is Hari");
12 |  }
13 |  x();
14 |  
15 |  ```
16 |  > This is Hari
17 |  
18 |  > 1 //after waiting 3 seconds (3000ms)
19 |  
20 |  We expect JS to wait 3 sec, print 1 and then go down and print the string. But JS prints string immediately, waits 3 sec and then prints 1.
21 |  
22 |  - The fun inside setTimeout forms a closure (remembers reference to i). So wherever fun goes it carries this ref along with it. 
23 |  - setTimeout takes this callback function & attaches timer of 3000ms and stores it. Goes to next line without waiting and prints string. 
24 |  - After 3000ms runs out, JS takes function, puts it into call stack and runs it. 
25 |  
26 |  #### Print 1 after 1 sec, 2 after 2 sec till 5 : Tricky interview question
27 |  
28 |  We assume this has a simple approach as below
29 |  
30 |  ```
31 |  function x() {
32 |   for(var i = 1; i<=5; i++){
33 |     setTimeout(function() {
34 |       console.log(i);
35 |      }, i*1000);
36 |     }
37 |     console.log("This is Hari");
38 |   }
39 |   x();
40 |   
41 |  ```
42 |  
43 |  > This is Hari
44 |  
45 |  > 6
46 |  
47 |  > 6
48 |  
49 |  > 6
50 |  
51 |  > 6
52 |  
53 |  > 6
54 |   
55 |  - This happens because of closures. When setTimeout stores the function somewhere and attaches timer to it, the fun remembers its reference to i, **not value of i**
56 |  - All 5 copies of fun point to same reference of i. 
57 |  - JS stores these 5 functions, prints string and then comes back to the functions. By then the timer has run fully. And due to looping, the i value became 6. And when the
58 |  callback fun runs the variable i = 6. So same 6 is printed in each log
59 |  - **To stop this from happening, use let instead of var** as let has black scope. For each iteration, the i is a new variable altogether(new copy of i). 
60 |  - Everytime setTimeout is run, the inside fun forms closure with new variable i
61 |  
62 |  #### Using let instead of var is the best option. But if asked to use var only..?
63 |  
64 |  ```
65 |  function x() {
66 |   for(var i = 1; i<=5; i++){
67 |     function close(i) {
68 |      setTimeout(function() {
69 |       console.log(i);
70 |      }, i*1000);
71 |      // put the setT fun inside new function close()
72 |     }
73 |     close(i); // everytime you call close(i) it creates new copy of i. Only this time, it is with var itself!
74 |    }
75 |     console.log("This is Hari");
76 |   }
77 |   x();
78 |   
79 |   ```
80 |  
81 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/12-JSInterview-Closures.md:
--------------------------------------------------------------------------------
 1 | ## Only the important new concepts
 2 | 
 3 | - Closures are used in encapsulation and data hiding. 
 4 | 
 5 | ```
 6 | (without closures)
 7 | var count = 0;
 8 | 
 9 | function increment(){
10 |   count++;
11 | }
12 | 
13 | in this code, anyone can access count and change it. 
14 | 
15 | (with closures) -> put everything into a function
16 | 
17 | function counter() {
18 |   var count = 0;
19 | 
20 |   function increment(){
21 |     count++;
22 |   }
23 | }
24 | console.log(count); // this will give referenceError as count can't be accessed.
25 | 
26 | (inc with function using closure)
27 | 
28 | function counter() {
29 |   var count = 0;
30 |   return function increment(){
31 |     count++;
32 |     console.log(count);
33 |   }
34 | }
35 | var counter1 = counter(); //counter fun has closure with count var. 
36 | counter1(); // increments counter
37 | 
38 | Above code is not good and scalable for say, when you plan to implement decrement counter at a later stage. 
39 | To address this issue, we use constructors
40 | 
41 | Adding decrement counter and refactoring code:
42 | 
43 | function Counter() { //constructor function. Good coding would be to capitalize first letter of ctor fun. 
44 |   var count = 0;
45 |   this.incrementCounter = function(){ //anonymous function
46 |     count++;
47 |     console.log(count);
48 |   }
49 |    this.decrementCounter = function(){
50 |     count--;
51 |     console.log(count);
52 |   }
53 | }
54 | 
55 | var counter1 = new Counter();  // new keyword for ctor fun
56 | counter1.incrementCounter();
57 | counter1.incrementCounter();
58 | counter1.decrementCounter();
59 | 
60 | // returns 1 2 1
61 | 
62 | ```
63 | ### Disadvantages of closure
64 | - Overconsumption of memory when using closure as everytime as those closed over variables are not garbage collected till program expires.
65 | So when creating many closures, more memory is accumulated and this can create memory leaks if not handled.
66 | - **Garbage collector** : Program in JS engine or browser that frees up unused memory. In highlevel languages like C++ or JAVA, garbage collection is left to the 
67 | programmer, but in JS engine its done implicitly.
68 | 
69 | ```
70 | function a() {
71 |   var x = 0;
72 |   return function b() {
73 |     console.log(x);
74 |    }
75 |  }
76 |  
77 |  var y = a(); // y is a copy of b()
78 |  y(); 
79 |  
80 |  Once a() is called, its element x should be garbage collected ideally. But fun b has closure over var x. So mem of x cannot be freed.
81 |  Like this if more closures formed, it becomes an issue. To tacke this, JS engines like v8 and Chrome have smart garbage collection mechanisms.
82 |  Say we have var x = 0, z = 10 inabove code. When console log happens, x is printed as 0 but z is removed automatically.   
83 | 
84 | ```


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/14-Functions.md:
--------------------------------------------------------------------------------
 1 | # Episode 14 : First class and Anonymous functions
 2 | 
 3 | (there is no Episode 13 idk why lol)
 4 | 
 5 | #### Function statement : Just your normal function definition 
 6 | 
 7 | ```
 8 | function a() {
 9 |   console.log("a called");
10 | }
11 | a();
12 | 
13 | ```
14 | 
15 | #### Function Expression : Assigning a function to a variable. Function acts like a value
16 | 
17 | ```
18 | var b = function() {
19 |   console.log("b called");
20 | }
21 | b();
22 | 
23 | ```
24 | 
25 | **Difference btw function statement and expression is Hoisting**
26 | - You can put "a();" before "function a()" and it will still work. But putting "b();" before "var b = function()" throws a typeError.
27 | - Why? During mem creation phase a is created in memory and function assigned to a. But b is created like a variable (b:undefined) and until code reaches the function() 
28 | part, it is still undefined. So it cannot be called.
29 | 
30 | #### Function Declaration : Exactly same as function statement
31 | 
32 | #### Anonymous Function : A function without a name
33 | - They don't have their own identity. So an anony function without code inside it results in an error. 
34 | - Anony functions are used when functions are used as values eg. the code sample for function expression above
35 | 
36 | #### Named Function Expression : Same as Function Expression but function has a name instead of being anonymous
37 | ```
38 | var b = function xyz() {
39 |   console.log("b called");
40 | }
41 | b(); // prints "b called" properly
42 | xyz(); // Throws ReferenceError:xyz is not defined.
43 | 
44 | ```
45 | > xyz function is not created in global scope. So it can't be called.
46 | 
47 | #### Parameters vs Arguments 
48 | ```
49 | var b = function(param1, param2) {  // labels/identifiers that get the arg values 
50 |   console.log("b called");
51 | }
52 | b(arg1, arg2); // arguments - values passed inside function call
53 | 
54 | ```
55 | #### First Class Function aka First Class Citizens
56 | - You can pass functions inside a function as arguments(WOW!)
57 | 
58 | ```
59 | var b = function(param1) {
60 |   console.log(param1); // prints " f() {} "
61 | }
62 | b(function(){
63 |   
64 | });
65 | 
66 | this can also be done:
67 | 
68 | var b = function(param1) {
69 |   console.log(param1);
70 | }
71 | function xyz(){
72 | 
73 | }
74 | b(xyz); // same thing as prev code
75 | 
76 | you can return a function from a function:
77 | 
78 | var b = function(param1) {
79 |   return function() {
80 |   
81 |   }  
82 | }
83 | console.log(b()); //we log the entire fun within b. 
84 | 
85 | ```
86 | #### Arrow Functions (latest in ES6 (ECMAScript 2015) -> coming in future lecture
87 | 
88 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/15-Callbacks-EventListeners.md:
--------------------------------------------------------------------------------
 1 | # Episode 15 : Callbacks and Event Listeners
 2 | 
 3 | **Callback Function :** Functions are first class citizens (see prev lecture) ie. take a fun A and pass it to another fun B. Here, A is a callback function
 4 | - JS is a synchronous and singlethreaded language. But due to callbacks, we can do async things in JS. 
 5 | 
 6 | > setTimeout(function () {}, 1000) -> here the anony function is a callback function as it is passed to setT and called sometime later in code after certain time (here 1000ms).
 7 | - This is how we do async things. JS is a synch language, but it doesn't wait 1 sec for setT to finish before going to code below it. It stores the function, attaches timer
 8 | and goes down the code. 
 9 | 
10 | ```
11 | setTimeout(function () {
12 |   console.log("timer");
13 |  }, 5000);
14 |  
15 | function x(y) {
16 |   console.log("x");
17 |   y();
18 | }
19 | 
20 | x(function y() {
21 |   console.log("y");
22 | });
23 | ```
24 | 
25 | > x
26 | 
27 | > y
28 | 
29 | > timer
30 | 
31 | - In the call stack, first x and y are present. After completion, they go away and stack is empty. Then after 5 seconds(from beginning) anonymous suddenly pops up in stack ie. setTimeout
32 | - All 3 functions are executed through call stack. If any operation blocks the call stack, its called **blocking the main thread**
33 | - Say if x() takes 30 sec to run, then JS has to wait for it to finish as it has only 1 call stack/1 main thread. *Never block main thread*. 
34 | - **Always use async for functions that take time eg. setTimeout**
35 | 
36 | **Event Listener** 
37 | 
38 | - When we create a button in HTML and attack a clickListener in JS :
39 | ```
40 | in index.html
41 | 
42 | <button id="clickMe">Click Me!</button>
43 | 
44 | in index.js
45 | 
46 | document.getElementById("clickMe").addEventListener("click", function xyz(){ //when event click occurs, this callback function is called into callstack
47 |     console.log("Button clicked");
48 | });
49 | ```
50 |  Suppose we want to increase count by 1 each time button clicked. 
51 |  - Use global variable (not good as anyone can change it)
52 |  
53 |  ```
54 |  let count = 0;
55 |  document.getElementById("clickMe").addEventListener("click", function xyz(){ 
56 |     console.log("Button clicked", ++count);
57 | });
58 |  ```
59 | - Use closures for data abstraction
60 | 
61 |  ```
62 |  function attachEventList() {  //creating new fun for closure
63 |     let count = 0;
64 |     document.getElementById("clickMe").addEventListener("click", function xyz(){ 
65 |     console.log("Button clicked", ++count);  //now callback fun forms closure with outer scope(count)
66 | });
67 | }
68 | attachEventList();
69 | ```
70 | 
71 | #### Garbage Collection and removeEventListeners 
72 | - Event listeners are heavy as they form closures. So even when call stack is empty, EventListener won't free up memory allocated to *count* as it doesn't know
73 | when it may need *count* again. 
74 | - **So we remove event listeners when we don't need them (garbage collected)**
75 | - onClick, onHover, onScroll all in a page can slow it down heavily. 
76 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/16-Async-EventLoops.md:
--------------------------------------------------------------------------------
  1 | # Episode 16 : Asynchronous JS and Event Loops
  2 | 
  3 | > Note that call stack will execeute any execeution context which enters it. Time, tide and JS waits for none. TLDR : Call stack has no timer
  4 | 
  5 | **Browser has JS Engine which has Call Stack which has Global exec context, local exec context etc**
  6 | - But browser has many other *superpowers* - Local storage space, Timer, place to enter URL, Bluetooth access, Geolocation access and so on
  7 | - Now JS needs some way to connect the callstack with all these superpowers. This is done using **Web APIs**
  8 | 
  9 | ### WebAPIs
 10 | None of the below are part of Javascript! These are extra superpowers that browser has. Browser gives access to JS callstack to use these powers.
 11 | > setTimeout(), DOM APIs, fetch(), localstorage, console (yes, even console.log is not JS!!), location and so many more..
 12 | 
 13 | - setTimeout() : Timer function 
 14 | - DOM APIs : eg.Document.xxxx ; Used to access HTML <html><script><body>..... DOM tree. (Document Object Manipulation)
 15 | - fetch() : Used to make connection with external servers eg. Netflix servers etc.
 16 | 
 17 | We get all these inside call stack through *global object* ie. **window**
 18 | - Use window keyword like : window.setTimeout(), window.localstorage, window.console.log() to log something inside console. 
 19 | - As window is global obj, and all the above functions are present in global object, we don't explicity write *window* but it is implied
 20 | 
 21 | ### Workflow
 22 | 
 23 | ```
 24 | // First a GEC is created and put inside call stack. 
 25 | console.log("Start"); // this calls the console web api (through window) which in turn actually modifies values in console. 
 26 | 
 27 | setTimeout(function cb() {  //this calls the setT web api which gives access to timer feature. It stores the callback cb() and starts timer.  
 28 |   console.log("Callback");
 29 |  }, 5000);
 30 |  
 31 | console.log("End"); // calls console api and logs in console window. After this GEC pops from call stack. 
 32 | 
 33 | ```
 34 | - While all this is happening, the timer is constantly ticking. After it becomes 0, the callback cb() has to run. 
 35 | - Now we need this cb to go into call stack. Only then will it be executed. For this we need **event loop and Callback queue**
 36 | 
 37 | ### Event Loops and Callback Queue
 38 | - cb() cannot simply directly go to callstack to be execeuted. It goes through the callback queue when timer expires. 
 39 | - Event loop checks the callback queue, and if it has element puts it into call stack. It is a *gate keeper*. 
 40 | - Now cb() in callstack is run. Console API is used and log printed
 41 | 
 42 | Final console output:
 43 |  
 44 | > Start
 45 | 
 46 | > End
 47 | 
 48 | > Callback
 49 | 
 50 | ### Same happens for any other event as well (Click, Hover etc). This is the basic workflow.
 51 | 
 52 | ```
 53 | console.log("Start"); 
 54 | document. getElementById("btn").addEventListener("click", function cb() { // cb() registered inside webapi environment and event(click) attached to it. ie.
 55 | // REGISTERING CALLBACK AND ATTACHING EVENT TO IT. 
 56 |   console.log("Callback");
 57 | });
 58 |  
 59 | console.log("End"); // calls console api and logs in console window. After this GEC pops from call stack. 
 60 | 
 61 | ```
 62 | In above code, even after console prints "Start" and "End" and pops GEC out, **the eventListener stays in webapi env**(with hope that user may click it
 63 | some day) until explicitly removed, or the browser is closed.
 64 | 
 65 | ### Why need callback queue? 
 66 | - Why can't event loop directly take cb() and put it in callstack?  Suppose user clciks button x6 times. So 6 cb() are put inside callback queue.
 67 | - Event loop sees if call stack is empty/has space and whether callback queue is not empty(6 elements here). 
 68 | - Elements of callback queue popped off, put in callstack, executed and then popped off from call stack.
 69 | 
 70 | ### fetch() works a bit different than the rest
 71 | ```
 72 | console.log("Start"); // this calls the console web api (through window) which in turn actually modifies values in console. 
 73 | 
 74 | setTimeout(function cbT() { 
 75 |   console.log("CB Timeout");
 76 |  }, 5000);
 77 |  
 78 |  fetch("https://api.netflix.com").then(function cbF() {
 79 |   console.log("CB Netflix");
 80 |  });
 81 |  
 82 | console.log("End"); 
 83 | 
 84 | ```
 85 | - Same steps for everything before fetch() in above code. 
 86 | - fetch registers cbF into webapi environment along with existing cbT. 
 87 | - cbT is waiting for 5000ms to end so that it can be put inside callback queue. cbF is waiting for data to be returned from Netflix servers. 
 88 | - fetch requests data from Netflix servers, and get data back and now cbF ready to be executed. 
 89 | **We have something called a Microtask Queue**
 90 | - It is exactly same as Callback queue, but it has higher priority. Functions in Microtask Q are executed earlier than Callback Q. 
 91 | - cbF goes inside the Microtask Q and not callback Q. Once call stack is empty, Event loop gives chance for elements in **both** Microtask Queue and 
 92 | Callback Queue to enter Call Stack. 
 93 | 
 94 | - In console, first *Start* and *End* are printed in console. First cbF goes in callstack and "CB Netflix" is printed. cbF popped from callstack
 95 | - Next cbT is removed from callback Q, put in Call Stack, "CB Timeout" is printed, and cbT removed from callstack.
 96 | 
 97 | ### What enters the Microtask Queue ?
 98 | - All the callback functions that come through *promises* go in microtask Q. 
 99 | - **Mutation Observer :** Keeps on checking whether there is mutation in DOM tree or not, and if there, then it execeutes some callback function. 
100 | - Callback functions that come through *promises and mutation observer* go inside Microtask Queue. 
101 | - All the rest goes inside **Callback Queue aka. Task Queue**
102 | 
103 | - If the task in microtask Queue keeps creating new tasks in the queue, element in callback queue never gets chance to be run. This is called **starvation**
104 | 
105 | ### Some Important Questions 
106 | 
107 | 1. **When does the event loop actually start ? -** Event loop, as the name suggests, is a single-thread, loop that is *almost infinite*. It's always running and doing its job.
108 | 
109 | 2. **Are only asynchronous web api callbacks are registered in web api environment? -** YES, the synchronous callback functions like what we pass inside map, filter and reduce aren't registered in the Web API environment. It's just those async callback functions which go through all this.
110 | 
111 | 3. **Does the web API environment stores only the callback function and pushes the same callback to queue/microtask queue? -** Yes, the callback functions are stored, and a reference is scheduled in the queues. Moreover, in the case of event listeners(for example click handlers), the original callbacks stay in the web API environment forever, that's why it's adviced to explicitly remove the listeners when not in use so that the garbage collector does its job.
112 | 
113 | 4. **How does it matter if we delay for setTimeout would be 0ms. Then callback will move to queue without any wait ? -** No, there are trust issues with setTimeout() 😅. The callback function needs to wait until the Call Stack is empty. So the 0 ms callback might have to wait for 100ms also if the stack is busy.
114 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/17-JSEngine-ChromeV8.md:
--------------------------------------------------------------------------------
 1 | # Episode 17 : JS Engine and Google v8 architecture
 2 | 
 3 | #### JS runs literally everywhere from smart watch to robots to browsers because of Javascript Runtime Environment (JRE)
 4 | 
 5 | - JRE consists of a JS Engine (❤️ of JRE), set of APIs to connect with outside environment, event loop, Callback queue, Microtask queue etc.
 6 | - JRE is a container that can run JS code.
 7 | 
 8 | - ECMAScript is a governing body of JS. It has set of rules followed by all JS engines like Chakra(Edge), Spidermonkey(Firefox), v8(Chrome)
 9 | - JS Engine is **not a machine**. Its software written in low level languages (eg. C++) that takes in hi-level code in JS and spits out low level machine
10 |   code
11 | 
12 | In all languages, code is compiled either with **interpreter** or with **compiler**. JS used to have only interpreter in old times, but now has **both**
13 | to compile JS code.
14 | 
15 | Interpreter : Takes code and executes line by line. Has no idea what will happen in next line. Very fast.
16 | Compiler : Code is compiled and an optimized version of same code is formed, and then executed. More efficient
17 | 
18 | - Code inside JRE passes through 3 steps : **Parsing, Compilation and Execution**
19 | 
20 | 1. **Parsing** - Code is broken down into tokens. In "let a = 7" -> let, a, =, 7 are all tokens. Also we have a **syntax parser** that takes code and converts it
21 |    into an **AST (Abstract Syntax Tree)** which is a JSON with all key values like type, start, end, body etc (looks like package.json but for a line of code in JS. Kinda
22 |    unimportant)(Check out astexplorer.net -> converts line of code into AST)
23 | 
24 | 2. **Compilation** - JS has something called **Just-in-time(JIT) Compilation - uses both interpreter & compiler**. Also compilation and execution both go hand in hand.
25 |    The AST from previous step goes to interpreter which converts hi-level code to byte code and moves to execeution. While interpreting, compiler also works hand in hand
26 |    to compile and form optimized code during runtime.
27 | 
28 | 3. **Execution** - Needs 2 components ie. Memory heap(place where all memory is stored) and Call Stack(same call stack from prev episodes). There is also a _garbage collector._
29 |    It uses an algo called **Mark and Sweep**.
30 | 
31 | Companies use different JS engines and each try to make theirs the best.
32 | 
33 | - v8 of Google has Interpreter called _Ignition_, a compiler called _Turbo Fan_ and garbage collector called _Orinoco_
34 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/17-setTimeout().md:
--------------------------------------------------------------------------------
 1 | # Episode 17 : Trust Issues with setTimeout() 
 2 | 
 3 | (Episode number mixup. This is the actual 17th episode)
 4 | 
 5 | ```
 6 | console.log("Start");
 7 | 
 8 | setTimeout(function cb() {
 9 |   console.log("Callback");
10 |  }, 5000);
11 |  
12 |  console.log("End");
13 |  
14 | setTimeout sometimes does not exactly guarantee that the callback method will be called exactly after 5s. 
15 | Maybe 6,7 or even 10! It all depends on callstack
16 | ```
17 | 
18 | While execution of program 
19 | 
20 | - First GEC is created and pushed in callstack. 
21 | - Start is printed in console
22 | - When setT is seen, callback method is registered into webapi's env. And timer is attached to it and started. cb waits for its turn to be execeuted once timer expires.
23 | But JS waits for none. Goes to next line
24 | - End is printed in console. 
25 | - After "End" suppose we have 1 million lines of code that runs for 10 sec(say). So GEC won't pop out of stack. It runs all the code for 10 sec. 
26 | - But in the background, the timer runs for 5s. While callstack runs the 1M line of code, this timer has already expired and cb fun has been pushed to Callback queue.
27 | - Event loop keeps checking if callstack is empty or not. But here GEC is still in stack so cb can't be popped from callback Q and pushed to CallStack. 
28 | ** Though setT is only for 5s, it waits for 10s until callstack is empty before it can execute**(When GEC popped after 10sec, cb() is pushed into call stack and 
29 | **immediately executed** (Whatever is pushed to callstack is executed instantly)
30 | - This is called as the **Concurrency model of JS**. This is the logic behind setT's trust issues
31 | 
32 | ### The First rule of JavaScript
33 | - **Do not block the main thread** (as JS is a single threaded(only 1 callstack) language)
34 | 
35 | - This raises a question. *Why not add more call stacks and make it multithreaded?* 
36 | - JS is a synch single threaded language. And thats its beauty. With just 1 thread it runs all pieces of code there. It becomes kind of an interpreter lang,
37 | and runs code very fast inside browser (no need to wait for code to be compiled) (JIT - Just in time compilation). And there are still ways to do async operations as well. 
38 | 
39 | ### Now what if the timeout = 0sec
40 | ```
41 | console.log("Start");
42 | 
43 | setTimeout(function cb() {
44 |   console.log("Callback");
45 |  }, 0);
46 |  
47 |  console.log("End");
48 |  
49 | ```
50 | - Even though timer = 0s, the cb() has to go through the queue. Registers calback in webapi's env , moves to callback queue, and execute once callstack is empty
51 | 
52 | > Start
53 | 
54 | > End
55 | 
56 | > Callback
57 | 
58 | - This method of putting timer = 0, can be used to defer a less imp fun by a little so the more important fun (here printing "End") can take place 
59 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/2-Execution-CallStack.md:
--------------------------------------------------------------------------------
 1 | # Episode 2 : Execution & Call Stack
 2 | 
 3 | Everytime you run a program, an execution context is created.
 4 | When a variable or function is encountered, it is stored in the memory area. 
 5 | 
 6 | ```
 7 | var n=2;
 8 | function square(num){
 9 |     var ans = num*num;
10 |     return ans;
11 | }
12 | 
13 | var square2 = square(n);
14 | var square4 = square(4);
15 | 
16 | ```
17 | Now first, for this entire code a <strong>Global</strong> execution context is created.
18 | 
19 | ### In the first phase (memory creation)
20 | - Memory is allocated to variables and functions.
21 | - For variable name(which is key) it assigns a value of <strong>undefined</strong>
22 | - For the function name(which is key) it assigns the entire function code as value.
23 | 
24 | ```
25 | n:undefined 
26 | square:{...entire-code...}
27 | square2:undefined 
28 | square4:undefined
29 | 
30 | ```
31 | 
32 | ### In the second phase (code execution)
33 | - The variable name is replaced with its actual assigned value from code. So now n:2 
34 | - Skips over function code as there is nothing to assign there. 
35 | - We encounter a function call in square2. So a brand new local EC is created inside the code part of global EC and this will have the same 2 components: Memory and Code. 
36 | - In the local EC, ans and num are both undefined (in first phase). Then, the n value in global EC is passed to num, replacing undefined. num is the parameter and n is the argument. 
37 | - ans = num*num (calculated in code part of local EC and returned) replaces undefined in local EC (memory part) and the final value is returned from local and is assigned to square2 var in global. 
38 |   After returning, local EC is removed form global EC and control goes back to global.
39 | - One more fun. call is met. Same thing happens here. 
40 | Once square4 value is replaced from undefined to 16, global EC will also be deleted. 
41 | 
42 | To manage all these EC, a call **stack** is created. Everytime code is run, the EC is pushed in. So first global EC is pushed. Then e1 EC(for square2) is pushed, and then after
43 | value returned, is popped. Similarly e2 EC(for square4) is pushed, and then popped and finally Global is also popped and stack is empty. 
44 | 
45 | > Call Stack maintains the order of execution of execution contexts
46 | #### Call stack aka Execution control stack, program stack, control stack, runtime stack ad machine stack
47 | 
48 | 
49 | 
50 | 
51 | 
52 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/3-Hoisting.md:
--------------------------------------------------------------------------------
  1 | # Episode 3 : Hoisting
  2 | 
  3 | ```
  4 | // code example 1
  5 | 
  6 | var x = 7;
  7 | 
  8 | function getName(){
  9 |     console.log("Namaste JavaScript");
 10 | }
 11 | 
 12 | getName();
 13 | console.log(x);
 14 | 
 15 | ```
 16 | 
 17 | Output:
 18 | 
 19 | > Namaste JavaScript
 20 | 
 21 | > 7
 22 | 
 23 | ```
 24 | // code example 2
 25 | 
 26 | getName();      // in most languages, both lines which are above their declaration will give error. Not in JS though.
 27 | console.log(x);
 28 | 
 29 | var x = 7;
 30 | 
 31 | function getName(){
 32 |     console.log("Namaste JavaScript");
 33 | }
 34 | 
 35 | ```
 36 | 
 37 | Output:
 38 | 
 39 | > Namaste JavaScript
 40 | 
 41 | > undefined
 42 | 
 43 | ```
 44 | // code example 3
 45 | 
 46 | getName();
 47 | console.log(x);
 48 | 
 49 | function getName(){
 50 |     console.log("Namaste JavaScript");
 51 | }
 52 | 
 53 | ```
 54 | 
 55 | Output:
 56 | 
 57 | > Namaste JavaScript
 58 | 
 59 | > Error: x is not defined // note that not defined here and "undefined" in
 60 | > sample 2 are totally different.
 61 | 
 62 | - Not defined: We have not initialised the value for variable anywhere in the
 63 |   entire code and in memory space.
 64 | - Undefined: It is a placeholder that is assigned to a variable by the
 65 |   Javascript Engine until the variable is assigned with some other value.
 66 | 
 67 | **Hoisting** is a concept which enables us to extract values of variables and
 68 | functions even before initialising/assigning value without getting _error_
 69 | 
 70 | ```
 71 | 
 72 | // code example 4
 73 | 
 74 | function getName(){
 75 |     console.log("Namaste JavaScript");
 76 | }
 77 | 
 78 | console.log(getName)
 79 | 
 80 | 
 81 | ```
 82 | 
 83 | Output:
 84 | 
 85 | > f getName(){
 86 | 
 87 |       console.log("Namaste JavaScript);
 88 | 
 89 | }
 90 | 
 91 | ```
 92 | 
 93 | // code example 5
 94 | 
 95 | getName();
 96 | console.log(x);
 97 | console.log(getName)
 98 | 
 99 | var x = 7;
100 | 
101 | function getName(){
102 |     console.log("Namaste JavaScript");
103 | }
104 | 
105 | ```
106 | 
107 | Output:
108 | 
109 | > Namaste JavaScript
110 | 
111 | > undefined
112 | 
113 | > f getName(){
114 | 
115 |       console.log("Namaste JavaScript);
116 | 
117 | }
118 | 
119 | ```
120 | // code example 6
121 | 
122 | console.log(getName)
123 | 
124 | var getName = function () {
125 |     console.log("Namaste JavaScript");
126 | }
127 | 
128 | var getName = () => {  // use fat arrow function
129 |     console.log("Namaste JavaScript");
130 | }
131 | 
132 | ```
133 | 
134 | Output:
135 | 
136 | > undefined //it is because they behave as variable and not function.
137 | 
138 | ---
139 | 
140 | **REASON OF WEIRDNESS**
141 | 
142 | - The answer lies in the Global Exection Context. In the memory phase, the
143 |   variables will be initialized as _undefined_ and functions will get the whole
144 |   function code in their memory.
145 | 
146 | - This is the reason why we are getting these outputs.
147 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/4-Fun-VarEnv.md:
--------------------------------------------------------------------------------
 1 | # Episode 4 : Functions and Variable Environments
 2 | 
 3 | ```
 4 | var x = 1;
 5 | a();
 6 | b();   // we are calling the functions before defining them. This will work properly, as seen in Hoisting (Ep3)
 7 | console.log(x);
 8 | 
 9 | function a() {
10 |   var x = 10;
11 |   console.log(x);
12 | }
13 | 
14 | 
15 | function b() {
16 |   var x = 100;
17 |   console.log(x);
18 | }
19 | 
20 | ```
21 | 
22 | Outputs:
23 | 
24 | > 10
25 | 
26 | > 100
27 | 
28 | > 1
29 | 
30 | ### Code Flow
31 | 
32 | - The Global Execution Context (GEC) is created (the big box with Memory and Code subparts). Also GEC is pushed into Call Stack
33 | > Call Stack : GEC
34 | - In first phase of GEC (memory phase), variable x:undefined and a and b have their entire function code as value initialized
35 | - In second phase of GEC (execution phase), when the fun is called, a new local EC is made. After x = 1 assigned to GEC x, a() is called. So local EC for a is made inside code part of GEC.
36 | > Call Stack: [GEC,a()]
37 | - For local EC, a totally different x variable assigned undefined(x inside a()) in phase 1 , and in phase 2 it is assigned 10 and printed in console log. After printing, no more
38 | commands to run, so a() local EC is removed from both GEC and from Call stack
39 | > Call Stack: GEC
40 | - Cursor goes back to b() function call. Same steps repeat.
41 | > Call Stack :[GEC, b()] -> GEC (after printing yet another totally different x value as 100 in console log)
42 | - Finally GEC is deleted and also removed from call stack. Program ends.
43 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/5-Window-this.md:
--------------------------------------------------------------------------------
 1 | # Episode 5: Window and this keyword
 2 | 
 3 | ### Everywhere JS is run, it is done with a JS execution engine. For Chrome: v8
 4 | 
 5 | - Shortest JS program is nothing but an Empty JS file
 6 | - Even for this program, JS engine does a lot behind the scenes
 7 | - It creates the GEC, the "window" and the *this* variable
 8 | - Window is a big global object that has a lot of functions and variables. All of these can be accessed from anywhere in the program
 9 | - *this* points to *window*
10 | > this === window -> true (at global level)
11 | ```
12 | var a = 10;      // not inside any fun. So global object
13 | function b() {    // this fun not inside any function. So global.
14 |   var x = 5;    // not global
15 |  }
16 | console.log(window.a); //gives us "a" value
17 | console.log(this.a); //this points to window so it returns "a" value
18 | console.log(a); //also gives same "a" value. (if we dont put any . in front of variable, it **assumes variable is in global space**
19 | console.log(x); // x is not defined. (tries to find x inside global space, but it isn't there) 
20 | ```
21 | - Global space is anything in JS which isn't inside a function. All these global objects will be present inside the windows schema. But non globals ones won't be there (here, x)
22 | - When a GEC is made, *this* is also created with it (even for functional(local) EC). Global object provided by the browser engine is the window, so *this* points to window.
23 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/6-Undef-NotDef.md:
--------------------------------------------------------------------------------
 1 | # Episode 6: Undefined vs Not Defined
 2 | 
 3 | - In first phase (mem alloc) JS assigns each variable to a placeholder called *undefined*
 4 | - *undefined* is when memory is allocated for the variable, but no value is assigned yet.
 5 | - If an object/variable is not even declared/found in mem alloc phase, and tried to access it then it is *Not defined*
 6 | 
 7 | > When variable is declared but not assigned value, its current value is undefined. But when the variable itself is not declared but called in code, then it is not defined. 
 8 | 
 9 | ```
10 | console.log(x);
11 | var x = 25;
12 | 
13 | console.log(x);
14 | console.log(a);
15 | 
16 | ```
17 | >undefined <br/>
18 | >25 <br/>
19 | >Uncaught ReferenceError: a is not defined
20 | 
21 | 
22 | - JS is a loosely-typed / weakly-typed language. It doesn't attach variables to any datatype. We can say var a = 5, and then change the value to bool (a = true) or string
23 | (a = 'hello') later on. 
24 | - **Never** assign *undefined* to a variable manually. Let it happen on it's own accord.
25 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/7-Scope-LexEnv.md:
--------------------------------------------------------------------------------
 1 | # Episode 7 : Scope and Lexical Environment
 2 | 
 3 | ```
 4 | This is why JS is confusing (Case-1)
 5 | 
 6 | function a() {
 7 |     console.log(b); // surprisingly instead of printing undefined it prints 10. 
 8 |     //So somehow this b could access the b outside the fun. 
 9 | }
10 | 
11 | var b = 10;
12 | a();
13 | 
14 | ---------------------
15 | 
16 | Another case: (Case-2)
17 | 
18 | function a() {
19 |   c();
20 |   function c() {
21 |   console.log(b); // when cursor comes here, it still prints out 10 somehow!!
22 |   }
23 |  }
24 |  var b = 10;
25 |  a();
26 |  
27 |  --------------------
28 |  
29 |  Another one (DJ KHALED!) (Case-3)
30 |  
31 |  function a() {
32 |   var b = 10;
33 |   c();
34 |   function c() {
35 |     console.log(b); //it prints the right value. How? See ans below Summary part
36 |   }
37 |  }
38 |  
39 |  a();
40 |  console.log(b); // now when cursor comes here, it prints NOT DEFINED!
41 | 
42 | ```
43 | 
44 | - This is the intuition behind **scope**
45 | - Scope is directly dependent on the lexical environment
46 | - **Lexical Environment** : local memory + lexical env of its parent
47 | - Whenever an EC is created, a Lexical environment(LE) is also created and is referenced in the local EC(in memory space)
48 | - Lexical means hierarchy. In the DJ KHALED (xD) code, function c is lexically inside function a. 
49 | - So in EC of c(), variables and fun in c (none) + reference of lexical env of parent a() is there
50 | - LE of a() in turn is its memory space + reference to LE of parent (Global EC)
51 | - LE of Global EC points to *null*
52 | 
53 |  ```
54 |     To summarize the above points:
55 |     
56 |     call_stack = [GEC, a(), c()]
57 | 
58 |     Now lets also assign the memory sections of each execution context in call_stack.
59 | 
60 |     c() = [[lexical environment pointer pointing to a()]]
61 | 
62 |     a() = [b:10, c:{}, [lexical environment pointer pointing to GEC]]
63 | 
64 |     GEC =  [a:{},[lexical_environment pointer pointing to null]]
65 | 
66 |  ```
67 |   ### For case -3 
68 |   - First JS engine searches for b in local mem of c(). Nothing is there. 
69 |   - So it goes to the reference of Lexical env of parent a(). Here b = 10 is here. So it takes this value, goes back to c() and console prints it.
70 |   - Had b not been in a(), then pointer would have gone to a()'s parent (Global EC and searched there). Had b not been there too, then it goes to LE of global's parent
71 |   which is null. Now JS engine stops and says b is NOT DEFINED. 
72 |   - **Lexical env of c = Local memory of c + LE of A + LE of Global**
73 |   - This process of going one by one to parent and checking is called **scope chain**
74 |  
75 |   
76 |   
77 | 
78 | 
79 | 
80 | 
81 | 
82 | 
83 | 
84 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/8-letConst-deadzone-errors.md:
--------------------------------------------------------------------------------
  1 | # Episode 8 : let, const, temporal dead zone, types of errors
  2 | 
  3 | > let and const declarations are hoisted. But its different from var
  4 | 
  5 | ```
  6 | 
  7 | console.log(a); // ReferenceError: Cannot access 'a' before initialization
  8 | console.log(b); // prints undefined as expected
  9 | let a = 10;
 10 | console.log(a); // 10
 11 | var b = 15;
 12 | 
 13 | ```
 14 | It looks like let isn't hoisted, **but it is**
 15 | 
 16 | - Both a and b are actually initialized as *undefined* in hoisting stage. But var b is inside the storage space of GLOBAL, and a is in a separate memory(script), where it can be
 17 | accessed only after assigning some value to it first.
 18 | - ie. one can access 'a' only if it is assigned. Thus, it throws error.
 19 | - **Temporal Dead Zone** : Time since when the let variable was hoisted until it is initialized some value. 
 20 | - So any line till before "let a = 10" is the TDZ for a
 21 | - Since a is not accessible on global, its not accessible in *window/this* also
 22 | > window.b or this.b -> 15; But window.a or this.a ->undefined, just like window.x->undefined (x isn't declared anywhere)
 23 | 
 24 | ```
 25 | let a = 10;
 26 | let a = 100;  //this code is rejected upfront as SyntaxError. (duplicate declaration)
 27 | ------------------
 28 | let a = 10;
 29 | var a = 100; // this code also rejected upfront as SyntaxError.
 30 | (can't use same name in same scope)
 31 | 
 32 | ```
 33 | Let is a stricter version of var. Now, **const** is even more stricter than let.
 34 | 
 35 | -const holds all above properties of let. 
 36 | 
 37 | ```
 38 | let a;
 39 | a = 10;
 40 | console.log(a) // prints 10 properly. Note declaration and assigning of a is in different lines.
 41 | ------------------
 42 | const b;
 43 | b = 10;
 44 | console.log(b); // SyntaxError: Missing initializer in const declaration.
 45 | (This type of declaration won't work with const. const b = 10 only will work)
 46 | ------------------
 47 | const b = 100;
 48 | b = 1000;
 49 | //this gives us TypeError: Assignment to constant variable. 
 50 | 
 51 | ```
 52 | - Till now 3 types of errors have been covered: Syntax, Reference, and Type.
 53 | 
 54 | * Uncaught ReferenceError: x is not defined at ...
 55 | 
 56 |     * This Error signifies that x has never been in the scope of the program. This literally means that x was never defined/declared and is being tried to be accesed.
 57 | 
 58 | * Uncaught ReferenceError: cannot access 'a' before initialization
 59 | 
 60 |     * This Error signifies that 'a' cannot be accessed because it is declared as 'let' and since it is not assigned a value, it is its Temporal Dead Zone. Thus, this error occurs.
 61 | 
 62 | * Uncaught SyntaxError: Identifier 'a' has already been declared
 63 | 
 64 |     * This Error signifies that we are redeclaring a variable that is 'let' declared. No execution will take place.
 65 | 
 66 |         ```
 67 |         //code example 1.1
 68 |         let a=10;
 69 |         let a=100;
 70 |         ```
 71 |         ```
 72 |         //code example 1.2
 73 |         let a=10;
 74 |         var a=100;
 75 |         ```
 76 |     
 77 |         Will throw this Syntax error and no code will be run and be rejected affront. 
 78 |         'let' is a strict form of declaration and thus can be done only once.
 79 | * Uncaught SyntaxError: Missing initializer in const declaration
 80 |     * This Error signifies that we haven't initialized or assigned value to a const declaration.
 81 | 
 82 | * Uncaught TypeError: Assignment to constant variable
 83 |     * This Error signifies that we are reassigning to a const variable.
 84 | 
 85 | 
 86 | ### Type Error:
 87 | 
 88 | The Errors that occur due to conflicts with the declaration type. For example re-assigning const type declaration will throw this.
 89 | 
 90 | ### Syntax Error:
 91 | 
 92 | The Errors that occur due to wrong syntax that doesn't match with JS Engine syntactical rules. 
 93 | 
 94 | For example, if const is not initialized, it will throw syntax error as by syntax, it must initialize if it sees a const declaration.
 95 | 
 96 | Also, if variable that is assigned with 'let' declaration is tried to re-declared, then it throws Syntax Error.
 97 | 
 98 | ### Reference Error
 99 | 
100 | The Errors that occurs if no reference is available for access. Can occur when the variable is no where in scope or maybe it is in temporal dead zone.
101 | 
102 | 
103 | ### SOME GOOD PRACTICES:
104 | 
105 | * Try using const wherever possible.
106 | * If not, use let.
107 | * Avoid var.
108 | * Declare and initialize all variables with let to the top to avoid errors to shrink temporal dead zone window to zero.
109 | 
110 | PS: If in any interview when asked "Are let and const hoisted?" explain fully about temporal deadzone and all the above concepts too
111 | 
112 | 
113 | 


--------------------------------------------------------------------------------
/JavaScript-A-Z-Notes-main/Notes/9-BlockScope-Shadowing.md:
--------------------------------------------------------------------------------
  1 | # Episode 9 : Block Scope and Shadowing
  2 | 
  3 | ### What is a block?
  4 | - Block aka *compound statement* is used to group JS statements together into 1 group. We group them within {...}
  5 | - The purpose is to group multiple statments at a place where JS expects only 1 statement.
  6 | 
  7 | ```
  8 | //code example 1
  9 | 
 10 | if(true)some statement
 11 | ```
 12 | 
 13 | But if we want to write more statements to execute after if condition; then:
 14 | 
 15 | ```
 16 | //code example 2
 17 | 
 18 | if(true){
 19 |     statement 1
 20 |     statement 2
 21 |     ...
 22 | }
 23 | ```
 24 | 
 25 | * The {} block treats all the statements as one statement.
 26 | * The if doesnt have any curly braces in syntax.
 27 | 
 28 | ### __BLOCK SCOPE__
 29 | 
 30 | * What are the variables and functions that can be accessed inside the block.
 31 | 
 32 | ```
 33 | //code example 3
 34 | 
 35 | {
 36 |     var a = 10;
 37 |     let b = 20;
 38 |     const c = 30;
 39 | }
 40 | 
 41 | console.log(a);
 42 | console.log(b);
 43 | ```
 44 | 
 45 | Outputs:
 46 | 
 47 | > 10
 48 | 
 49 | > Uncaught ReferenceError: b is not defined
 50 | 
 51 | * Behind the Scenes:
 52 | 
 53 |     * In the BLOCK SCOPE; we get b and c inside it initialized as *undefined* as a part of hoisting (in a seperate memory space called block)
 54 |     * While, a is stored inside a GLOBAL scope. 
 55 | 
 56 | * Thus we say, *let* and *const* are BLOCK SCOPED. They are stored in a separate mem space which is reserved for this block. Also, they can't be accessed outside this block.
 57 | But var a can be accessed anywhere as it is in global scope.
 58 | * Thus, we can't access them outside the Block.
 59 | 
 60 | ### __What is SHADOWING in JS?__
 61 | 
 62 | ```
 63 | //code example 4
 64 | 
 65 | var a = 100;
 66 | {
 67 |     var a = 10; //same name as global var
 68 |     let b = 20;
 69 |     const c = 30;
 70 |     console.log(a); // 10
 71 |     console.log(b); // 20
 72 |     console.log(c); // 30 
 73 | }
 74 | 
 75 | console.log(a); // 10 instead of the 100 we were expecting. So block "a" modified val of global "a" as well. 
 76 | // In console, only b and c are in block space. a initially is in global space(a = 100), and when a = 10 line is run, a is not created in block space, but replaces 100 with 10 in global space itself. 
 77 | ```
 78 | 
 79 | * If one has same named variable outside the block, the variable inside the block *shadows* the outside variable.
 80 | * So, a is reassigned to 10. Since both refers to same memory space i.e GLOBAL SPACE. **This happens only for var**
 81 | 
 82 | ### Instead of var let us use let
 83 | ```
 84 | //code example 5
 85 | 
 86 | let b = 100;
 87 | {
 88 |     var a = 10;
 89 |     let b = 20;
 90 |     const c = 30;
 91 |     console.log(b);
 92 | }
 93 | 
 94 | console.log(b);
 95 | ```
 96 | 
 97 | Outputs:
 98 | 
 99 | > 20
100 | 
101 | > 100  // this was what we were expecting in this first place. Both b's are in separate spaces (one in Block(20) and one in Script(another arbitrary mem space)(100))
102 | 
103 | * In the Scope, we have b in two places. The b outside of the block is in *Script* SCOPE (seperate memory space for let and const)
104 | * The b inside the block is in *Block* scope.
105 | * Thus, when in Block scope, 20 is printed and 100 when outside.
106 | * This concept is called "Shadowing".
107 | * It is also true for *const* declarations.
108 | 
109 | ### Same logic is true even for functions
110 | 
111 | ```
112 | const c = 100;
113 | function x() {
114 |   const c = 10;
115 |   console.log(c);
116 | }
117 | x();
118 | console.log(c);
119 | 
120 | ```
121 | Output:
122 | > 10
123 | 
124 | > 100
125 | 
126 | ### __What is Illegal Shadowing?__
127 | 
128 | ```
129 | // code example 6
130 | 
131 | let a = 20;
132 | {
133 |     var a = 20;
134 | }
135 | 
136 | ```
137 | 
138 | Outputs:
139 | 
140 | > Uncaught SyntaxError: Identifier 'a' has already been declared
141 | 
142 | * We cannot shadow let with var. But it is valid to shadow a let using a let.
143 | * However, we can shadow var with let.
144 | * All scope rules that work in function are same in arrow functions too.
145 | * Since var is function scoped, it is not a problem with the code below.
146 | 
147 | ```
148 | // code example 7
149 | 
150 | let a = 20;
151 | function x() {
152 |     var a = 20;
153 | }
154 | 
155 | ```
156 | 
157 | 
158 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # JS_NOTES


--------------------------------------------------------------------------------
/javascript_notes.md:
--------------------------------------------------------------------------------
   1 | ### How JavaScript Works?
   2 | 
   3 | > Is JavaScript:
   4 | >
   5 | > - <i><mark>**Synchronous**</mark> or Asynchronous?</i>
   6 | > - <i><mark>**Single-threaded**</mark> or Multi-threaded?</i>
   7 | 
   8 | - Everything in JavaScript happens inside an **Execution Context**
   9 |   - You can assume this _execution context_ to be a big box or a container in which the whole JavaScript code is executed.
  10 |   - This **big box** has two components in it:
  11 |     - **Memory:** This is the place where all variables and functions are stored as key-value pairs. This _'memory component'_ is also known as the **Variable Environment**. So, it's sort of an environment in which all these variables and functions are stored as key-value pairs.
  12 |     - **Code:** This is the place where the code is executed one line at a time. This _'code component'_ is also known as the **Thread of Execution**. So, this _thread of execution_ is just like a thread in which the whole code is executed one line at a time.
  13 | - JavaScript is a **_synchronous single-threaded_** language.
  14 |   - **Single-threaded** means that JavaScript can only execute one command at a time.
  15 |   - **Synchronous single-threaded** means that JavaScript can only execute one command at a time and in a specific order. That means that it can only go to the next line once the current line has finished executing. This is what it means by being **_synchronous single-threaded_**.
  16 | 
  17 | ---
  18 | 
  19 | ### How JavaScript Code is executed?
  20 | 
  21 | **What happens when you run JavaScript code?**
  22 | 
  23 | > _An <mark>**Execution Context**</mark> is created._
  24 | 
  25 | Let's take an example using some code.
  26 | 
  27 | ```js
  28 | var n = 2;
  29 | function square(num) {
  30 |   var ans = num * num;
  31 |   return ans;
  32 | }
  33 | var square2 = square(n);
  34 | var square4 = square(4);
  35 | ```
  36 | 
  37 | - When the above code is executed, an **Execution Context** is created
  38 |   - This **Execution Context** is created in 2 phases:
  39 |     - **Creation:** The **Creation Phase** is also known as the **Memory Creation Phase**. This is a very critical phase.
  40 |       - In the first phase of _memory creation_, JavaScript will allocate memory to all the variables and functions.
  41 |       - As soon as JavaScript encounters `var n = 2;`, it allocates memory to `n`.
  42 |       - On encountering the function `square(num)`, it allocates memory to this function (`square`) as well.
  43 |       - When it allocates memory to `n`, it stores a special value called `undefined`. `undefined` is treated like a special placeholder in JavaScript.
  44 |       - In case of the function `square(num)`, it stores the entire code of this function in the memory space.
  45 |       - It will also allocate memory to `square2` and `square4` and store `undefined` for both.
  46 |       - In order to complete this **Creation** phase, JavaScript goes through the code, line by line, top to bottom.
  47 |     - **Code Execution:**
  48 |       - Now JavaScript once again runs through this whole program line by line.
  49 |       - When it encounters `var n = 2;`, it actually places `2` as a value for `n` in the **Memory Component**.
  50 |       - When it encounters the function definition of `square(num)`, it has nothing to execute, so JavaScript simply passes through.
  51 |       - When it encounters `var square2 = square(n);`, we are now invoking a function.
  52 |       - Functions are the heart of JavaScript. They behave very differently in JavaScript than in any other language.
  53 |       - Whenever a function is invoked, an all together new **Execution Context** is created.
  54 |       - So, technically, a brand new **Execution Context** is created inside the **Code Component** of the overall **Execution Context**.
  55 |       - This new **inner Execution Context** also has its own **Memory Component** and the **Code Component**.
  56 |       - What happens in the **innner** one now is:
  57 |         - We have 2 variables in this case, namely `num` (which is the parameter) and `ans`.
  58 |         - So memory will be allocated to `num` and `ans`.
  59 |         - In phase 1, alike the overall Execution Context, `undefined` will be assigned to `num` and `ans`.
  60 |         - Now coming to phase 2 (code execution phase), the value of the argument is assigned to the parameter. So, in the statement `var square2 = square(n);` where we are invoking a function, we're passing the argument `n` to the function `square(num)` and the value of this argument replaces the placeholder `undefined` in the **Memory Component** of the **inner Execution Context**.
  61 |         - After calculation of `num * num`, the value is stored in `ans`.
  62 |         - On encountering `return ans;`, the value stored in `ans` is returned to the invoked location and this **inner Execution Context** ends. When it ends, it actually gets deleted.
  63 |       - Now, the same process is followed when the line `var square4 = square(4);` is encountered.
  64 |       - After successful execution of the last line, the **overall Execution Context** also gets deleted. This _'overall'_ execution context is also termed as the **Global Execution Context**.
  65 | 
  66 | > Now, how does JavaScript manage this _'chaining'_ of **Execution Contexts**?
  67 | 
  68 | - It actually manages a stack under the hood.
  69 | - This stack is also termed as the **Call Stack**.
  70 | - The **GEC** (Global Execution Context) is always at the bottom of this stack.
  71 | - Whenever a new Execution Context is created, it is pushed in this stack and on completion of its purpose, it gets popped.
  72 | - The control stays with the topmost element of this _Call Stack_.
  73 | - This _Call Stack_ is only used to manage the **Execution Context(s)**.
  74 | - On successful execution of the last statement, the **Call Stack** is emptied.
  75 | 
  76 | > **Call Stack** maintains the <mark>**_order of execution_**</mark> of Execution Contexts.
  77 | 
  78 | The **Call Stack** has the following fancy names by which it is also referred:
  79 | 
  80 | - Execution Context Stack
  81 | - Program Stack
  82 | - Control Stack
  83 | - Runtime Stack
  84 | - Machine Stack
  85 | 
  86 | ---
  87 | 
  88 | ### Hoisting in JavaScript
  89 | 
  90 | Let's take 2 code blocks for example.
  91 | 
  92 | First block:
  93 | 
  94 | ```js
  95 | var x = 7;
  96 | 
  97 | function getName() {
  98 |   console.log("Namaste JavaScript");
  99 | }
 100 | 
 101 | getName();
 102 | console.log(x);
 103 | ```
 104 | 
 105 | Output:
 106 | 
 107 | ```
 108 | Namaste JavaScript
 109 | 7
 110 | ```
 111 | 
 112 | Second block:
 113 | 
 114 | ```js
 115 | getName();
 116 | console.log(x);
 117 | 
 118 | var x = 7;
 119 | 
 120 | function getName() {
 121 |   console.log("Namaste JavaScript");
 122 | }
 123 | ```
 124 | 
 125 | Output:
 126 | 
 127 | ```
 128 | Namaste JavaScript
 129 | undefined
 130 | ```
 131 | 
 132 | In most programming languages, code similar to the second block will throw errors, but that's not the case in JavaScript.
 133 | 
 134 | If we remove the statement `var x = 7;` from the second code block, which becomes like this:
 135 | 
 136 | ```js
 137 | getName();
 138 | console.log(x);
 139 | 
 140 | function getName() {
 141 |   console.log("Namaste JavaScript");
 142 | }
 143 | ```
 144 | 
 145 | It will now throw the following error:
 146 | 
 147 | ```
 148 | Uncaught ReferenceError: x is not defined at...
 149 | ```
 150 | 
 151 | Now, **not defined** and **undefined** are 2 different things.
 152 | 
 153 | All these scenarios are due to something called **Hoisting** in JavaScript.
 154 | 
 155 | **Hoisting**
 156 | 
 157 | - **Hoisting** is a phenomena in JavaScript by which we can access variables and functions even before initializing them.
 158 | 
 159 | - The result of **Hoisting**, i.e., the memory allocation that happens due to which we are able to access variables and functions even before initializing them, can be viewed in the developer tools. Also, we have a debugger in the developer tools by which we can stop execution of our code and check for ourselves the value that is stored against the variables and functions even before start of the execution.
 160 | 
 161 | **Not Defined** VS **Undefined**
 162 | 
 163 | > **Not Defined** means that the variable or function is not present in the memory, while **Undefined** acts simply as a placeholder for any value which is not defined yet, but memory is reserved for the same.
 164 | 
 165 | Suppose we now have the following code block where `getName` is an arrow function:
 166 | 
 167 | ```js
 168 | getName();
 169 | 
 170 | var getName = () => {
 171 |   console.log("Namaste JavaScript");
 172 | };
 173 | ```
 174 | 
 175 | On execution of the above code, we'll face the following error:
 176 | 
 177 | ```
 178 | Uncaught TypeError: getName is not a function at ...
 179 | ```
 180 | 
 181 | The reason for this error is that when we declare `getName()` as an arrow function, it behaves like any other variable. Meaning that the value stored in memory for `getName()` is `undefined` at the first line of the given code block.
 182 | 
 183 | Even if we declare a function as follows:
 184 | 
 185 | ```js
 186 | var getName2 = function () {
 187 | 	...
 188 | }
 189 | ```
 190 | 
 191 | It will again behave like a variable.
 192 | 
 193 | Also, the **Call Stack** can be viewed in the developer tools. Hence the flow of control of the entire execution of the program can be easily monitored using the developer tools. The **GEC** (Global Execution Context) is referred to as **anonymous** in the **Call Stack** shown in the developer tools.
 194 | 
 195 | ---
 196 | 
 197 | ### How functions work in JavaScript?
 198 | 
 199 | Sample code:
 200 | 
 201 | ```js
 202 | var x = 1;
 203 | a();
 204 | b();
 205 | console.log(x);
 206 | 
 207 | function a() {
 208 |   var x = 10;
 209 |   console.log(x);
 210 | }
 211 | 
 212 | function b() {
 213 |   var x = 100;
 214 |   console.log(x);
 215 | }
 216 | ```
 217 | 
 218 | Sample output:
 219 | 
 220 | ```
 221 | 10
 222 | 100
 223 | 1
 224 | ```
 225 | 
 226 | - Imagine the **Call Stack** and **Execution Contexts** for the above code.
 227 | - Each variable `x` is treated differently.
 228 | - The variable `x` declared inside each function is different than the `x` declared in the global context.
 229 | - Whenever we invoke a function, an **inner Execution Context** is created and we have a new `x` inside the _memory component_ of this **inner Execution Context**.
 230 | - When we reach the statement `console.log(x);`, we're actually retrieving `x` _from the memory of the local context and not the global context._
 231 | 
 232 | ---
 233 | 
 234 | ### SHORTEST JS Program
 235 | 
 236 | **`window` and `this` keyword**
 237 | 
 238 | The **shortest JavaScript program** would be **_an empty script_**.
 239 | 
 240 | Even though there's an empty script, still JavaScript engine is doing a lot of things behind the scenes.
 241 | 
 242 | Even on the execution of an empty script, a **GEC** (Global Execution Context) would be created and the JavaScript engine also sets up the memory space, though there is nothing to set as per our **empty** script.
 243 | 
 244 | On going to the console and typing the following:
 245 | 
 246 | ```
 247 | > window
 248 | ```
 249 | 
 250 | We do get some output.
 251 | 
 252 | Technically the `window` is like a big object with a lot of key-value pairs which typically stores different objects.
 253 | 
 254 | Even if our script is empty, the `window` is not.
 255 | 
 256 | The functions and variables in the `window` object are created by the JavaScript engine. Also, these are created into the global space, meaning we can access all these variables and functions anywhere in our JS program.
 257 | 
 258 | Also, just like the `window` object, the JavaScript engine creates something called `this`, which can also be logged on the console, just like the `window` object.
 259 | 
 260 | At the global level, the `this` points to the `window` object.
 261 | 
 262 | But, **What is `window`?**
 263 | 
 264 | `window` is actually a global object which is created along with the global execution context. So, whenever any JavaScript program is run, _a **global object** is created, a **GEC** is created, and along with that execution context a **`this`** variable is created._
 265 | 
 266 | Every JavaScript engine is responsible to create a global object similar to `window` on execution of a script. In case of browsers, this object is known as `window`. In case of **Node**, it's something else. But, wherever we might run our JavaScript program, one thing is for certain that _this global object would be created_, even if our script be empty.
 267 | 
 268 | At the global level, `this === window` returns `true` (in case of browsers).
 269 | 
 270 | Whenever an **Execution Context** is created, a `this` is created along with it, _even for functional execution contexts_. At the global level, the `this` points to the global object, which is `window` in case of browsers.
 271 | 
 272 | If we have a script with some code in it, then this global object would contain all the variables and functions which are at the global scope post **Hoisting**.
 273 | 
 274 | Suppose we have `var a = 10;` in the global scope, then all of the following statements are equivalent:
 275 | 
 276 | ```js
 277 | console.log(window.a);
 278 | console.log(a);
 279 | console.log(this.a);
 280 | ```
 281 | 
 282 | So, once again, the shortest program in JavaScript is:
 283 | 
 284 | ```js
 285 | 
 286 | ```
 287 | 
 288 | ---
 289 | 
 290 | ### Undefined VS Not Defined in JavaScript
 291 | 
 292 | `undefined` is a very special keyword in JavaScript, which is not there in other languages. This keyword has a lot to do with how JavaScript code is executed.
 293 | 
 294 | As discussed earlier, JavaScript code is executed in a different way. It creates a **GEC** (Global Execution Context) and allocates memory to all the variables and functions (which are present at the global scope) even before a single line of code is executed. Here is where `undefined` comes into picture.
 295 | 
 296 | When JavaScript allocates memory to all the variables and functions, to the variables it tries to put a placeholder. `undefined` is treated like a placeholder which is placed in the memory. So, technically, `undefined` takes up some memory space. It's totally different than `not defined`.
 297 | 
 298 | So, while creating the memory component, the JavaScript engine allocates `undefined` to all the variables before execution begins.
 299 | 
 300 | Sample code:
 301 | 
 302 | ```js
 303 | console.log(a);
 304 | var a = 7;
 305 | console.log(a);
 306 | ```
 307 | 
 308 | Sample output:
 309 | 
 310 | ```
 311 | undefined
 312 | 7
 313 | ```
 314 | 
 315 | So, coming to `not defined`, `not defined` refers to something which has not been allocated memory.
 316 | 
 317 | `undefined` can be taken as a placeholder for the time being until a value is assigned replacing this placeholder.
 318 | 
 319 | Sample code:
 320 | 
 321 | ```js
 322 | var a;
 323 | 
 324 | if (a === undefined) {
 325 |   console.log("a is undefined");
 326 | } else {
 327 |   console.log("a is not undefined");
 328 | }
 329 | ```
 330 | 
 331 | Sample output:
 332 | 
 333 | ```
 334 | a is undefined
 335 | ```
 336 | 
 337 | **_JavaScript is a loosely typed language_**. Loosely typed means that it does not attach it's variables to any specific data type. That means that the data type of the data being stored in a variable can change from time to time. In this case, JavaScript is very flexible. In strict type languages like C, C++, Java, etc., every variable is associated with a data type, that means that a variable of type `String` in Java will only be able to store data of type `String`, so on and so forth.
 338 | 
 339 | Sample code:
 340 | 
 341 | ```js
 342 | var a;
 343 | console.log(a);
 344 | a = 10;
 345 | console.log(a);
 346 | a = "hello world";
 347 | console.log(a);
 348 | ```
 349 | 
 350 | Sample output:
 351 | 
 352 | ```
 353 | undefined
 354 | 10
 355 | hello world
 356 | ```
 357 | 
 358 | Hence, JavaScript is a loosely typed language. Loosely typed language is also termed as weakly typed language. That does not mean that JavaScript is weak in any sense though.
 359 | 
 360 | Also, even though `undefined` is a placeholder in JavaScript, it really is a bad practice to use it in assignments. The reason being that this could lead to a lot of inconsistencies.
 361 | 
 362 | ```js
 363 | // bad practice
 364 | a = undefined;
 365 | ```
 366 | 
 367 | ---
 368 | 
 369 | ### The Scope Chain - Scope & Lexical Environment
 370 | 
 371 | Scope in JavaScript is directly related to Lexical Environment. The Lexical Environment is a very classic concept in JavaScript.
 372 | 
 373 | Sample code:
 374 | 
 375 | ```js
 376 | function a() {
 377 |   console.log(b);
 378 | }
 379 | var b = 10;
 380 | a();
 381 | ```
 382 | 
 383 | Sample output:
 384 | 
 385 | ```
 386 | 10
 387 | ```
 388 | 
 389 | Justification:
 390 | 
 391 | When the function is invoked as `a();`, the JavaScript engine looks for `b` in the local memory space of `a()`. Failing to find it, it then searches for the same a level up, the global memory space in this case, and finds the value `10` assigned to `b`.
 392 | 
 393 | If, suppose, `b` weren't available in the upper level, and there were more levels preceding the current level, it'll search for `b` in the upper levels, till either it finds it or we run out of levels, which happens when one reaches the global memory space.
 394 | 
 395 | Sample code:
 396 | 
 397 | ```js
 398 | function a() {
 399 |   c();
 400 |   function c() {
 401 |     console.log(b);
 402 |   }
 403 | }
 404 | var b = 10;
 405 | a();
 406 | ```
 407 | 
 408 | Sample output:
 409 | 
 410 | ```
 411 | 10
 412 | ```
 413 | 
 414 | Let's take another example.
 415 | 
 416 | Sample code:
 417 | 
 418 | ```js
 419 | function a() {
 420 |   var b = 10;
 421 |   c();
 422 |   function c() {}
 423 | }
 424 | a();
 425 | console.log(b);
 426 | ```
 427 | 
 428 | The above code will face the following error:
 429 | 
 430 | ```
 431 | Uncaught ReferenceError: b is not defined at ...
 432 | ```
 433 | 
 434 | Here's where scope comes into picture.
 435 | 
 436 | > Scope is basically where you can access a particular data member.
 437 | 
 438 | There are 2 aspects to Scope:
 439 | 
 440 | - What is the scope of this (referring to the current) variable? Meaning, where can I access this variable?
 441 | - Is this variable inside the local (referring to the Local Execution Context) scope?
 442 | 
 443 | The Scope is directly dependent on the Lexical Environment.
 444 | 
 445 | > _Whenever an **Execution Context** is created, a **Lexical Environment** is also created._
 446 | 
 447 | Lexical Environment is the local memory along with the Lexical Environment of its parent. Lexical, as a term, means in hierarchy, or in a sequence.
 448 | 
 449 | Corresponding to the above code block, we can say that the `c()` is lexically sitting inside `a()`. In terms of code, it's basically where a particular data member is located. Corresponding to that, we can say that `a()` is lexically inside the global scope.
 450 | 
 451 | Whenever a new Execution Context is created, in the memory component of this Execution Context, we also get a reference to the Lexical Environment to its parent. In case of the Global Execution Context, this reference points to `null`.
 452 | 
 453 | It can be visualized by the diagram below, in correspondence to the above code.
 454 | 
 455 | ![lexical-env-visualization-js.png](https://i.ibb.co/Tm4WsH9/lexical-env-visualization-js.png)
 456 | 
 457 | So, technically when a variable is not found in the current local memory, the engine searches for that variable in the reference which points to the lexical parent and continues this process until the variable is found or we hit `null`. This search mechanism works on the basis of the **Scope Chain**. So, _the **Scope Chain** is the chain of all these lexical environments and their parent references._
 458 | 
 459 | So, whenever an Execution Context is created, a Lexical Environment is also created, which is a part of the memory component of this Execution Context. This Lexical Environment is actually a reference to the memory component of the lexical parent of the current Execution Context and in case of the **GEC** (Global Execution Context), this reference points to `null`.
 460 | 
 461 | > So, a variable is `not defined` when this **Scope Chain** is exhausted and the variable is not found.
 462 | 
 463 | The **Scope Chain** can be visualized by using the developer tools of any modern browser.
 464 | 
 465 | ![scope-chain-dev-tools.png](https://i.ibb.co/pwKFHZK/scope-chain-dev-tools.png)
 466 | 
 467 | ---
 468 | 
 469 | ### `let` and `const` in JS - Temporal Dead Zone
 470 | 
 471 | - **What is a Temporal Dead Zone?**
 472 | - **Are `let` & `const` declarations hoisted?**
 473 | - **SyntaxError vs. ReferenceError vs. TypeError**
 474 | 
 475 | `let` and `const` declarations are hoisted. But, they are hoisted very differently than the `var` declarations. Technically the `let` and `const` declarations spend some time in the **Temporal Dead Zone**.
 476 | 
 477 | Sample code:
 478 | 
 479 | ```js
 480 | console.log(b);
 481 | let a = 10;
 482 | var b = 100;
 483 | ```
 484 | 
 485 | Sample output:
 486 | 
 487 | ```
 488 | undefined
 489 | ```
 490 | 
 491 | Sample code:
 492 | 
 493 | ```js
 494 | console.log(a);
 495 | let a = 10;
 496 | var b = 100;
 497 | ```
 498 | 
 499 | In the above code, we'll face the following issue:
 500 | 
 501 | ```
 502 | Uncaught ReferenceError: Cannot access 'a' before initialization at ...
 503 | ```
 504 | 
 505 | So, according to the above error, we can only access `a` after we've initialized it. But, _how to know whether this variable was hoisted or not?_
 506 | 
 507 | Let's go into the developer tools and check for ourselves what's going on.
 508 | 
 509 | ![let-allocated-in-script-and-not-global.png](https://i.ibb.co/wpbMVrx/let-allocated-in-script-and-not-global.png)
 510 | 
 511 | As shown in the above screenshot, we can see that JavaScript has allocated memory to `a` in the `Script` section, but for `b` it has done the same in the `Global` section. Now the question arises is, _what is this `Script`?_
 512 | 
 513 | Memory was assigned to `b`, to the `var` declaration, and it was attached to the global object. But, in case of `let` and `const`, they are also allocated memory, which is what we call as **Hoisting**. But, the difference is that `let` and `const` declarations are stored in a different memory space than global, and we cannot access them unless they are assigned a value. This is how **Hoisting** works in case of `let` and `const` declarations.
 514 | 
 515 | In case of the above code, in which the execution is paused using a debugger, even if we run the entire script, the `let` and `const` declarations with still remain in the `Script` section of the memory. The point to consider is whether we'll be able to access them or not. Well, we'll be able to access only when a value is assigned to them.
 516 | 
 517 | **What is a Temporal Dead Zone?**
 518 | 
 519 | **Temporal Dead Zone** is the time interval for a certain data member, from when it is declared till when a value is assigned to it in the memory space. For example, in the code in the above screenshot, the **Temporal Dead Zone** is the time interval from the time the `let` declaration was hoisted till the time it was assigned a value. So, the **Temporal Dead Zone** for a data member ends the moment a value is assigned to it.
 520 | 
 521 | Whenever we try to access a variable when it is in the **Temporal Dead Zone**, we get a `ReferenceError`.
 522 | 
 523 | Another type of `ReferenceError` is when we're trying to access something which is `not defined`.
 524 | 
 525 | In case of `var` declarations, we can access the data members from the `window` object (in case of browsers). But that is not the case for `let` and `const` declarations. If we try to do something like `this.a` or `window.a` in the global scope relative to the above code, we'll get `undefined` in return, which we get for anything which is absent as a key in the `window` object.
 526 | 
 527 | Sample Code:
 528 | 
 529 | ```js
 530 | let a = 10;
 531 | let a = 100;
 532 | ```
 533 | 
 534 | In case of the above code, we'll face the following issue:
 535 | 
 536 | ```
 537 | Uncaught SyntaxError: Identifier 'a' has already been declared
 538 | ```
 539 | 
 540 | So, this means that we're unable to do a re-declaration using `let`.
 541 | 
 542 | Also, in case of `SyntaxError`s, none of the statements of the code are executed.
 543 | 
 544 | For instance, the code below:
 545 | 
 546 | ```js
 547 | console.log("something");
 548 | let a = 10;
 549 | let a = 100;
 550 | ```
 551 | 
 552 | Will face the same `SyntaxError` situation and nothing will be executed.
 553 | 
 554 | This phenomena is also observed in the following code:
 555 | 
 556 | ```js
 557 | let a = 10;
 558 | var a = 100;
 559 | ```
 560 | 
 561 | But, the following code snippet is totally valid:
 562 | 
 563 | ```js
 564 | var b = 100;
 565 | var b = 1000;
 566 | ```
 567 | 
 568 | Now, coming to `const`. `const` behaves much more similar than how `let` behaves, but it is a little more stricter than `let`.
 569 | 
 570 | For instance, we can do a `let` declaration without initialization and initialize the same later. But, we're unable to do the same in case of a `const` declaration.
 571 | 
 572 | Sample code:
 573 | 
 574 | ```js
 575 | const b;
 576 | ```
 577 | 
 578 | We'll face the following issue in the above code:
 579 | 
 580 | ```
 581 | Uncaught SyntaxError: Missing initializer in const declaration
 582 | ```
 583 | 
 584 | This means that whenever we're going for a `const` declaration, it expects to get initialized in the same line.
 585 | 
 586 | Sample code:
 587 | 
 588 | ```js
 589 | const b = 10;
 590 | b = 100;
 591 | ```
 592 | 
 593 | We'll face the following issue in the above code snippet:
 594 | 
 595 | ```
 596 | Uncaught TypeError: Assignment to constant variable ...
 597 | ```
 598 | 
 599 | Now, let us come to the difference between these 3 types of errors.
 600 | 
 601 | The `TypeError` which we see in case of trying to reinitialize a `const` variable is due to the fact that the variable is of type `const` and hence it is meant to be a constant.
 602 | 
 603 | We face `SyntaxError`s whenever we violate the rules of the syntax.
 604 | 
 605 | We face `ReferenceError`s when the JavaScript Engine tries to find some variable inside the memory space but it's unable to access it.
 606 | 
 607 | Now, according to certain conventions followed by the community, always use `const` wherever possible. This reduces the possibility of unexpected errors. If not `const` then we should use `let`, since due to the presence of the **Temporal Dead Zone**, we won't face unexpected errors.
 608 | 
 609 | Keep `var` aside. But, even if you ever feel the need to use `var`, use it very consciously. Otherwise, it is an un-preferred method of declaration.
 610 | 
 611 | Also, in an attempt to reduce issues being faced due to the **Temporal Dead Zone**, always try to put all the declarations and initializations at the top of the script. This technically shrinks the **Temporal Dead Zone** to zero.
 612 | 
 613 | ---
 614 | 
 615 | ### Block Scope & Shadowing in JS
 616 | 
 617 | `let` and `const` are **Block Scoped**.
 618 | 
 619 | The following is a perfectly valid JS code.
 620 | 
 621 | ```js
 622 | {
 623 | }
 624 | ```
 625 | 
 626 | Anything which is enclosed between `{` and `}` is a block. Even if there's nothing to enclose.
 627 | 
 628 | Blocks are also referred to as **Compound Statement**.
 629 | 
 630 | The use of a **Compound Statement** comes in handy when we need to group a bunch of statements into a single block and use in places where JavaScript expects only one statement.
 631 | 
 632 | For instance, `if` in JavaScript expects only one statement. But in case we need to execute multiple statements following an `if` case, we'll use a block, since a block is treated as a single statement, referred to as a **Compound Statement**.
 633 | 
 634 | **What is Block Scope?**
 635 | 
 636 | **Block Scope** means what all data members we can access within a block.
 637 | 
 638 | Let us take some code for instance and check out the developer tools for the same.
 639 | 
 640 | ```js
 641 | {
 642 |   var a = 10;
 643 |   let b = 20;
 644 |   const c = 30;
 645 | }
 646 | ```
 647 | 
 648 | ![let-const-block-scoped-dev-tools.png](https://i.ibb.co/JpyL7ZK/let-const-block-scoped-dev-tools.png)
 649 | 
 650 | As shown in the image above, we've got `b` and `c` inside the `Block` scope. They are hoisted and assigned `undefined`. They are hoisted in a separate memory space which is reserved for their block. But, we see that `a` is hoisted inside the `Global` scope.
 651 | 
 652 | _`let` and `const` are block scoped_, which means that a separate memory space is reserved for the block of which the `let` and `const` declarations are a part of.
 653 | 
 654 | We would be able to access `a` outside the block, since it's hoisted as part of the `Global` scope. That's not the case for the `let` and `const` declarations.
 655 | 
 656 | **Shadowing**
 657 | 
 658 | Sample code:
 659 | 
 660 | ```js
 661 | var a = 100;
 662 | {
 663 |   var a = 10;
 664 |   console.log(a);
 665 | }
 666 | console.log(a);
 667 | ```
 668 | 
 669 | Sample output:
 670 | 
 671 | ```
 672 | 10
 673 | 10
 674 | ```
 675 | 
 676 | The inner `a` shadowed the outer `a` and the value was also overridden, reason for which we got the above output. This happened since both of them were pointing to the same memory location, the global memory space in this case.
 677 | 
 678 | Shadowing works differently in case of `let` and `const`.
 679 | 
 680 | Sample code:
 681 | 
 682 | ```js
 683 | let b = 100;
 684 | {
 685 |   var b = 20;
 686 |   console.log(b);
 687 | }
 688 | console.log(b);
 689 | ```
 690 | 
 691 | Sample output:
 692 | 
 693 | ```
 694 | 20
 695 | 100
 696 | ```
 697 | 
 698 | So, we see that the inner `b` shadowed the outer `b`, but since both of these are referring to different memory spaces, the inner `b` didn't override the outer `b`. If we analyze the code using developer tools, we see that the inner `b` is part of the `Block` scope, while the outer `b` is part of the `Script` scope. According to the dev tools, we see that there are 3 memory spaces or scopes, namely `Block`, `Script` and `Global`.
 699 | 
 700 | **Illegal Shadowing**
 701 | 
 702 | Sample code:
 703 | 
 704 | ```js
 705 | let a = 20;
 706 | {
 707 |   var a = 200;
 708 | }
 709 | ```
 710 | 
 711 | We'll face the following error in the above code.
 712 | 
 713 | ```
 714 | Uncaught SyntaxError: Identifier 'a' has already been declared
 715 | ```
 716 | 
 717 | This is an example of **Illegal Shadowing**.
 718 | 
 719 | But, if we tried the same thing with both the declarations being of either `let` or `const`, then legal shadowing could have occurred.
 720 | 
 721 | But the following is also a case of legal shadowing.
 722 | 
 723 | ```js
 724 | var a = 200;
 725 | {
 726 |   let a = 20;
 727 | }
 728 | ```
 729 | 
 730 | Let's dig deep with the earlier code.
 731 | 
 732 | ```js
 733 | let a = 20;
 734 | {
 735 |   var a = 200;
 736 | }
 737 | ```
 738 | 
 739 | If a data member is attempting to shadow another data member, it shouldn't cross the boundary of its scope. In a particular scope, `let` cannot be re-declared.
 740 | 
 741 | Now, `var` is **function scoped**. This means that the following piece of code is totally valid.
 742 | 
 743 | ```js
 744 | let a = 20;
 745 | function x() {
 746 |   var a = 200;
 747 | }
 748 | ```
 749 | 
 750 | **Block Scope** follows **Lexical Scope**.
 751 | 
 752 | Also, the concept of scope in case of arrow functions is exactly the same as what we encounter in case of normal functions in JavaScript.
 753 | 
 754 | ---
 755 | 
 756 | ### Closures in JavaScript
 757 | 
 758 | Sample code:
 759 | 
 760 | ```js
 761 | function x() {
 762 |   var a = 7;
 763 |   function y() {
 764 |     console.log(a);
 765 |   }
 766 |   y();
 767 | }
 768 | x();
 769 | ```
 770 | 
 771 | Sample output:
 772 | 
 773 | ```
 774 | 7
 775 | ```
 776 | 
 777 | Dev tools snap:
 778 | 
 779 | ![closure-dev-tools.png](https://i.ibb.co/Tw20htF/closure-dev-tools.png)
 780 | 
 781 | **Closure** basically means a function bind together with its lexical environment. In other words, a function along with its lexical scope forms a **Closure**.
 782 | 
 783 | In the above screenshot, we have paused the execution at `console.log(a);`. We see that inside `y()` it forms a closure with its lexical parent, `x()` in this case.
 784 | 
 785 | _Let's see what the MDN says about Closures:_
 786 | 
 787 | > A **closure** is the combination of a function bundled together (enclosed) with references to its surrounding state (the **lexical environment**). In other words, a closure gives you access to an outer function’s scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.
 788 | 
 789 | In JavaScript, functions are very flexible in nature. We can assign functions to variables. We can even pass an entire function as a parameter to another function while calling.
 790 | 
 791 | The below code snippet it totally valid (provided that `x` is already defined):
 792 | 
 793 | ```js
 794 | x(function y() {
 795 |   console.log(a);
 796 | });
 797 | ```
 798 | 
 799 | Moreover, we are also allowed to return a function from a function in JavaScript. This is where the concept of closures kind of complicate things.
 800 | 
 801 | Sample code:
 802 | 
 803 | ```js
 804 | function x() {
 805 |   var a = 7;
 806 |   function y() {
 807 |     console.log(a);
 808 |   }
 809 |   return y;
 810 | }
 811 | var z = x();
 812 | z();
 813 | ```
 814 | 
 815 | Sample output:
 816 | 
 817 | ```
 818 | 7
 819 | ```
 820 | 
 821 | Now here **closure** comes into picture. When a function is returned from another function, they still maintain their lexical scope. They remember where they were actually present. Meaning, `y()` remembers where it came from. It means that when we returned `y()`, it's not just that the function code was returned, but a closure enclosed function along with its lexical scope was returned.
 822 | 
 823 | The following code snippet is equivalent to the last one.
 824 | 
 825 | ```js
 826 | function x() {
 827 |   var a = 7;
 828 |   return function y() {
 829 |     console.log(a);
 830 |   };
 831 | }
 832 | var z = x();
 833 | z();
 834 | ```
 835 | 
 836 | Whenever we return a function, the references to the data members as part of the closure are retained instead of being garbage collected.
 837 | 
 838 | _Uses of **Closures**:_
 839 | 
 840 | - Module Design Pattern
 841 | - Currying
 842 | - Functions like once
 843 | - Memoize
 844 | - Maintaining state in async world
 845 | - setTimeouts
 846 | - Iterators
 847 | - and many more...
 848 | 
 849 | ---
 850 | 
 851 | ### `setTimeout` & Closures
 852 | 
 853 | **Interview Question:** _Print 1-5 with a lapse of 1 second between each digit._
 854 | 
 855 | Sample code:
 856 | 
 857 | ```js
 858 | function x() {
 859 |   var i = 1;
 860 |   setTimeout(function () {
 861 |     console.log(i);
 862 |   }, 3000);
 863 | }
 864 | x();
 865 | ```
 866 | 
 867 | The above code prints `1` after 3 seconds.
 868 | 
 869 | Sample code:
 870 | 
 871 | ```js
 872 | function x() {
 873 |   var i = 1;
 874 |   setTimeout(function () {
 875 |     console.log(i);
 876 |   }, 3000);
 877 |   console.log("Namaste JavaScript");
 878 | }
 879 | x();
 880 | ```
 881 | 
 882 | In the above code, `Namaste JavaScript` is printed before `1`, which in turn is printed after 3 seconds of a lapse.
 883 | 
 884 | What `setTimeout` does is, first its callback function forms a closure. Meaning it remembers the reference to `i`. Wherever this function goes, it takes the reference of `i` along with it. What `setTimeout` does is, it takes this callback function and stores it in some place and attaches a timer to it, and the rest of the code proceeds. Once the timer runs out, the `setTimeout` places that callback function to the call stack and runs it.
 885 | 
 886 | Sample code:
 887 | 
 888 | ```js
 889 | function x() {
 890 |   for (var i = 1; i <= 5; i++) {
 891 |     setTimeout(function () {
 892 |       console.log(i);
 893 |     }, i * 1000);
 894 |   }
 895 | 
 896 |   console.log("Namaste JavaScript");
 897 | }
 898 | x();
 899 | ```
 900 | 
 901 | Sample output:
 902 | 
 903 | ```
 904 | Namaste JavaScript
 905 | 6
 906 | 6
 907 | 6
 908 | 6
 909 | 6
 910 | ```
 911 | 
 912 | **[NOTE:** All the lines with `6` are printed after a delay of 1 second.**]**
 913 | 
 914 | This behavior was observed because of the closure.
 915 | 
 916 | A closure is like a function along with its lexical environment. So, even when a function is taken out from its original scope, if it's executed in some other scope, it still remembers its lexical environment. Meaning it can access those variables of its lexical scope.
 917 | 
 918 | So what happens is, when the `setTimeout` takes this function and stores it somewhere and attaches a timer, the function remembers the reference to `i`. _It remembers the reference, not the value._
 919 | 
 920 | So, when the above code is executed, all 5 copies of the function are pointing to the same reference of `i`.
 921 | 
 922 | Sample code:
 923 | 
 924 | ```js
 925 | function x() {
 926 |   for (let i = 1; i <= 5; i++) {
 927 |     setTimeout(function () {
 928 |       console.log(i);
 929 |     }, i * 1000);
 930 |   }
 931 | 
 932 |   console.log("Namaste JavaScript");
 933 | }
 934 | x();
 935 | ```
 936 | 
 937 | Sample output:
 938 | 
 939 | ```
 940 | Namaste JavaScript
 941 | 1
 942 | 2
 943 | 3
 944 | 4
 945 | 5
 946 | ```
 947 | 
 948 | **[NOTE:** All the digits are printed after a lapse of 1 second.**]**
 949 | 
 950 | Now, this behavior is observed in the case of this code since we've used `let`. The reason being that `let` is block scoped, which means that for every iteration, every `i` is a new copy all together and each time the `setTimeout` function is called, its callback function has a new copy of `i` with it. It forms a closure with a new variable each time. Each time the function is called, it is referring to a different memory location.
 951 | 
 952 | But, there's a workaround that we can achieve this even by using `var`.
 953 | 
 954 | Sample code:
 955 | 
 956 | ```js
 957 | function x() {
 958 |   for (var i = 1; i <= 5; i++) {
 959 |     function close(i) {
 960 |       setTimeout(function () {
 961 |         console.log(i);
 962 |       }, i * 1000);
 963 |     }
 964 |     close(i);
 965 |   }
 966 | 
 967 |   console.log("Namaste JavaScript");
 968 | }
 969 | ```
 970 | 
 971 | So, _we've formed a closure_. We created a function `close` and enclosed the `setTimeout` within it. Also, we're passing the value of `i` to this function `close`. This works because every time we call this `close` function with this `i`, it creates a new copy of `i` for itself when we **pass by value**.
 972 | 
 973 | ---
 974 | 
 975 | ### More on Closures
 976 | 
 977 | Sample code:
 978 | 
 979 | ```js
 980 | function outer() {
 981 |   var a = 10;
 982 |   function inner() {
 983 |     console.log(a);
 984 |   }
 985 |   return inner;
 986 | }
 987 | outer()();
 988 | ```
 989 | 
 990 | Sample output:
 991 | 
 992 | ```
 993 | 10
 994 | ```
 995 | 
 996 | In the last statement of the code we have `outer()();`. This statement actually executes the inner function. It is able to do so as per the syntax since invoking the `outer()` returns `inner` which we are in turn calling by chaining another pair of `()`.
 997 | 
 998 | One example of data hiding using closures would be the following:
 999 | 
1000 | ```js
1001 | function counter() {
1002 |   var count = 0;
1003 |   return function incrementCounter() {
1004 |     count++;
1005 |     console.log(count);
1006 |   };
1007 | }
1008 | var counter1 = counter();
1009 | counter1();
1010 | ```
1011 | 
1012 | If we try to access `count` outside the function `counter()`, we'll get a `ReferenceError` of it being `not defined`.
1013 | 
1014 | Sample code:
1015 | 
1016 | ```js
1017 | function counter() {
1018 |   var count = 0;
1019 |   return function incrementCounter() {
1020 |     count++;
1021 |     console.log(count);
1022 |   };
1023 | }
1024 | 
1025 | var counter1 = counter();
1026 | counter1();
1027 | counter1();
1028 | 
1029 | var counter2 = counter();
1030 | counter2();
1031 | ```
1032 | 
1033 | Sample output:
1034 | 
1035 | ```
1036 | 1
1037 | 2
1038 | 1
1039 | ```
1040 | 
1041 | This behavior is observed since each time we call `counter`, we get a fresh reference of the function being returned.
1042 | 
1043 | A more preferred way of creating a `Counter` would be using a constructor function.
1044 | 
1045 | Sample code:
1046 | 
1047 | ```js
1048 | function Counter() {
1049 |   var count = 0;
1050 |   this.incrementCounter = function () {
1051 |     count++;
1052 |     console.log(count);
1053 |   };
1054 |   this.decrementCounter = function () {
1055 |     count--;
1056 |     console.log(count);
1057 |   };
1058 | }
1059 | var counter1 = new Counter();
1060 | 
1061 | counter1.incrementCounter();
1062 | counter1.incrementCounter();
1063 | counter1.decrementCounter();
1064 | ```
1065 | 
1066 | Sample output:
1067 | 
1068 | ```
1069 | 1
1070 | 2
1071 | 1
1072 | ```
1073 | 
1074 | **A disadvantage of closures:**
1075 | 
1076 | There could be an over consumption of memory in closures. This happens since the references enclosed in closures are not garbage collected and if not handled properly, might lead to memory leaks.
1077 | 
1078 | **What is a garbage collector and what does it do?**
1079 | 
1080 | Garbage collector is like a program in the browser or in the JavaScript engine which frees up the un-utilized memory. In languages like **C** and **C++**, it's up to the developers to allocate and de-allocate memory, but in high level languages like JavaScript, the garbage collector frees up the memory by releasing space attached to data members which are not in use, meaning when they are no longer needed.
1081 | 
1082 | **Relationship between garbage collector and closures**
1083 | 
1084 | Sample code:
1085 | 
1086 | ```js
1087 | function a() {
1088 |   var x = 0;
1089 |   return function b() {
1090 |     console.log(x);
1091 |   };
1092 | }
1093 | var y = a();
1094 | y();
1095 | ```
1096 | 
1097 | In the above code, `x` is enclosed with `b` and `b` is being returned and stored in `y`. The means that the garbage collector is unable to release the memory allocated to `x`, since the function stored in `y` can be invoked anywhere in the code, which in turn has a dependency on the variable `x`.
1098 | 
1099 | But in some modern browsers and engines, for instance V8 in Chrome, have smart garbage collection mechanisms where if it finds out that somehow this variable is unreachable then it smartly collects the garbage variables. For example, if we had another variable outside `b` and inside `a` alongside `x`, then once the function `b` was returned, then any variable other than `x` would be garbage collected in V8 of Chrome. This happens since it's clear from the code that `b` has a dependency on only `x` for the moment being, and unless we use any other variable from `b`'s lexical parent, there's no other dependency on its lexical parent.
1100 | 
1101 | ---
1102 | 
1103 | ### First Class Functions
1104 | 
1105 | - What is an Anonymous function?
1106 | - What is a First Class Function?
1107 | - Function Statement vs. Function Expression vs. Function Declaration
1108 | 
1109 | ```js
1110 | // Function Statement AKA Function Declaration
1111 | function a() {
1112 |   console.log("a called");
1113 | }
1114 | 
1115 | // Function Expression
1116 | // [Functions in JavaScript act like values which we can assign to variables]
1117 | var b = function () {
1118 |   console.log("b called");
1119 | };
1120 | 
1121 | // Anonymous Function
1122 | // A function without a name
1123 | // The following will result in a syntax error.
1124 | // function () {
1125 | // }
1126 | 
1127 | // Named Function Expression
1128 | var b = function xyz() {
1129 |   console.log("b called");
1130 | };
1131 | 
1132 | // Difference between Parameters & Arguments
1133 | function fun(param1, param2) {
1134 |   console.log(param1, param2);
1135 | }
1136 | fun(arg1, arg2);
1137 | ```
1138 | 
1139 | **Function Statement vs. Function Expression**
1140 | 
1141 | The major difference between these 2 is hoisting.
1142 | 
1143 | In the above code block, we have `a()` and `b()`. If we call `a()` before it's declaration, it's valid, but if we do the same for `b()`, we get a `TypeError` stating that `b is not a function`.
1144 | 
1145 | During the hoisting phase, during the memory creation phase, `a` is allocated some memory and the function definition of `a` is assigned to it. But, in case of our function expression, `b` is treated like another variable. `b` is assigned undefined initially until the code hits the line of `b`'s initialization.
1146 | 
1147 | **Anonymous Functions**
1148 | 
1149 | An anonymous function doesn't have its own identity.
1150 | 
1151 | The following will result in a syntax error.
1152 | 
1153 | ```js
1154 | function () {
1155 | 
1156 | }
1157 | ```
1158 | 
1159 | We'll face the following issue in the above code.
1160 | 
1161 | ```
1162 | Uncaught SyntaxError: Function statements require a function name
1163 | ```
1164 | 
1165 | Anonymous Functions don't have a name, but according to the ECMAScript specification, every function should have a name. Hence the above is an invalid syntax.
1166 | 
1167 | _**Anonymous functions** are used in places where functions are **used as values**._
1168 | 
1169 | **First Class Functions**
1170 | 
1171 | The ability to use functions as values is known as First Class Functions. Functions are First Class Citizens in JavaScript. The concept of First Class Functions and First Class Citizens is the same.
1172 | 
1173 | ---
1174 | 
1175 | ### Callback Functions
1176 | 
1177 | **What is a callback function in JavaScript?**
1178 | 
1179 | Functions are First Class Citizens in JavaScript. That means that we can take a function and pass it to another function. When we do so, this function which we've passed to another function is known as a callback function.
1180 | 
1181 | But, why the term **callback**? The reason being that we give the responsibility of calling our callback function to another function. It's up to that function, in which we've passed our callback, to decide when to invoke the callback.
1182 | 
1183 | **Blocking the main thread**
1184 | 
1185 | The **Call Stack** in JavaScript is AKA the **Main Thread**. Everything, whatever is executed inside your page, is executed through the **Call Stack** only.
1186 | 
1187 | If any operation blocks this **Call Stack**, then that is known as _blocking the main thread_.
1188 | 
1189 | Hence, we should always use `async` operations for anything that takes time and hence unblocks the **Call Stack**.
1190 | 
1191 | A niche example will be the `setTimeout` function.
1192 | 
1193 | Hence, this means that if JavaScript didn't have the concept of **First Class Citizens** and **Callback Functions**, then we wouldn't be able to perform `async` operations.
1194 | 
1195 | **Event Listeners**
1196 | 
1197 | Suppose we have a button with an id of `clickMe`, and we have the following event listener for the same.
1198 | 
1199 | ```js
1200 | document.getElementById("clickMe").addEventListener("click", function xyz() {
1201 |   console.log("Botton Clicked");
1202 | });
1203 | ```
1204 | 
1205 | So, here `xyz()` is our callback function. Although, we didn't need to name our function and could've kept it anonymous, this just helps to provide better visibility in the dev tools.
1206 | 
1207 | So, this function `xyz()` will be pushed to the call stack whenever we receive the `"click"` event.
1208 | 
1209 | But, suppose we want to add a counter of the frequency of clicks and log the same, we can achieve that by using a global variable, but that's not a conventional solution.
1210 | 
1211 | Instead, we can take the help of a closure here.
1212 | 
1213 | ```js
1214 | function attachEventListener() {
1215 |   let count = 0;
1216 |   document.getElementById("clickMe").addEventListener("click", function xyz() {
1217 |     console.log("Button clicked", ++count);
1218 |   });
1219 | }
1220 | attachEventListener();
1221 | ```
1222 | 
1223 | Now, once we run the above code, the callback function basically remembers the reference to `count` and remembers where it is present.
1224 | 
1225 | If we click the button 3 times, we'll get the following output:
1226 | 
1227 | ```
1228 | Button Clicked 1
1229 | Button Clicked 2
1230 | Button Clicked 3
1231 | ```
1232 | 
1233 | If we analyze the button in our HTML using the dev tools, we can see something like this:
1234 | 
1235 | ![event-listener-and-handler-dev-tools.png](https://i.ibb.co/QvrbfPY/event-listener-and-handler-dev-tools.png)
1236 | 
1237 | Now, the `handler` which we see in the image is our callback function `xyz()`.
1238 | 
1239 | If we dig a little deep, we see that we can also see the `Scopes` of this `handler`.
1240 | 
1241 | ![scopes-of-handler-dev-tools.png](https://i.ibb.co/YNQG144/scopes-of-handler-dev-tools.png)
1242 | 
1243 | This is the same scope that the function carries, the same lexical scope. Inside the scope, we'll have the `Closure`. So, we see that the `Global` environment and parent environment are all bundled up together in the lexical scope of the `handler`.
1244 | 
1245 | **INTERVIEW QUESTION**
1246 | 
1247 | > **_Why do we need to remove event listeners?_**
1248 | 
1249 | > Event listeners are heavy, meaning they take up a chunk of memory. Whenever we attach event listeners in our code, even if the **Call Stack** might be empty, the memory is still allocated to our event listeners and we can't simply free up this memory.
1250 | 
1251 | > This is the reason why we need to remove event listeners when we're not using them. Suppose our page has quite a bit of buttons with numerous event listeners attached, then our page might become much slower due to all the closures consuming a lot of memory for all the scopes and callback functions. If we remove our event listeners, then all the unnecessary data members will be garbage collected.
1252 | 
1253 | ---
1254 | 
1255 | ### Asynchronous JavaScript & Event Loop
1256 | 
1257 | So, JavaScript is a synchronous single threaded language. It has one call stack and it can only do one thing at a time. This call stack is present inside the JavaScript engine, and all the code is executed inside this call stack.
1258 | 
1259 | Whenever any JavaScript program is run, a **GEC** (Global Execution Context) is created and is pushed inside the call stack.
1260 | 
1261 | In case of any function invocation, a new Execution Context is created for that function and is pushed in the call stack. After executing all the statements of this invoked function, the execution context of this function is then popped from the call stack.
1262 | 
1263 | If we have more function invocations, more execution contexts will be created and the process of execution follows and the execution context is popped from the call stack once execution of all statements comes to completion.
1264 | 
1265 | Also, once we come to the end of our JavaScript program, the statements in the global scope also reach to an end, which means that after execution of all the statements in our global scope, the **GEC** (Global Execution Context) is also popped from the call stack.
1266 | 
1267 | So, the call stack of the JavaScript engine doesn't wait. Once something is pushed in this call stack, it quick executes it until all the statements are done with and the execution context is popped from the call stack.
1268 | 
1269 | Now, the call stack resides in the JavaScript engine and this JavaScript engine resides in another environment, which can typically be a browser in case of any web application. Many a times, the code needs to interact with elements which the browser has access to. This can be the local storage, bluetooth, timer, address bar, the HTML being rendered, etc.
1270 | 
1271 | The code does so by the help of web APIs.
1272 | 
1273 | Some of them would be:
1274 | 
1275 | - setTimeout()
1276 | - DOM APIs
1277 | - fetch()
1278 | - localStorage
1279 | - console
1280 | - location
1281 | 
1282 | **`setTimeout()` is not a part of JavaScript.**
1283 | 
1284 | _Even the DOM APIs are not a part of JavaScript_.
1285 | 
1286 | **_All the above mentioned web APIs are actually not a part of JavaScript. Instead they are the part of the browser._**
1287 | 
1288 | It is the browser which gives the JavaScript Engine access to all these web APIs.
1289 | 
1290 | Now, we're able to access these functionalities and execution follows in the call stack, all because of the global object.
1291 | 
1292 | In case of browsers, this global object is the `window`.
1293 | 
1294 | The reason we don't need to access the web APIs through the `window` keyword is due to the fact that the `window` is the global object. `window.setTimeout` is the same as `setTimeout`.
1295 | 
1296 | The browser wraps up the web APIs into the global object, `window` in this case, and hence provides access of these APIs to the JavaScript Engine.
1297 | 
1298 | **How `setTimeout` works? How does the callback function enter the call stack?**
1299 | 
1300 | The callback function of `setTimeout` enters the call stack through something called the **Callback Queue**. When we add a callback function to `setTimeout`, the callback function gets registered inside the web APIs environment with a timer. When the timer expires, the callback function is put inside this **Callback Queue**. We also have something called the **Event Loop**. The job of the **Event Loop** is to check this **Callback Queue** and put the functions of the **Callback Queue** into the call stack, and the call stack quickly executes.
1301 | 
1302 | **How does the callback function work in case of event listeners?**
1303 | 
1304 | When we add an event listener, the callback function is registered in the web APIs environment along with an event (`"click"` for example). Whenever this event occurs, the callback function is put inside the **Callback Queue** and it waits for its turn to get executed.
1305 | 
1306 | Now comes the **Event Loop**. The **Event Loop** has only one job. It's only job is to continuously monitor the **Call Stack** and the **Callback Queue**. If the **Event Loop** observes that the **Call Stack** is empty and also sees that there's something inside the **Callback Queue**, waiting to be executed, it takes that function and pushes it to the **Call Stack**.
1307 | 
1308 | **So, why do we need both the Event Loop and the Callback Queue?**
1309 | 
1310 | We need them for the fact that the **Callback Queue** helps us to manage the order of execution of the callbacks. The **Event Loop** on the other hand monitors the **Call Stack** and takes something from the **Callback Queue** only when it sees that the **Call Stack** is **_empty_**.
1311 | 
1312 | **How does fetch work?**
1313 | 
1314 | `fetch` is used to request an API call. The `fetch` function returns a promise. A callback is executed once this promise is resolved.
1315 | 
1316 | Now, we have something called the **Microtask Queue**, _which has higher priority over the_ **Callback Queue**, which implicitly means that whatever comes in the **Microtask Queue** will be executed prior to the elements of the **Callback Queue**.
1317 | 
1318 | In case of promises, in case of network calls using `fetch`, once the promise is resolved, the callback enters the **Microtask Queue**.
1319 | 
1320 | The **Event Loop** also monitors the **Microtask Queue** and hence pushes a callback from this queue to the **Call Stack** once it sees that the **Call Stack** is vacant.
1321 | 
1322 | Now, all callback functions which are registered against promises, will enter the **Microtask Queue**.
1323 | 
1324 | Also, we have something called the **Mutation Observer**, and callbacks against this also enters the **Microtask Queue**. The **Mutation Observer** keeps on checking whether there's a mutation in the **DOM** tree or not and executes a callback on the basis of that.
1325 | 
1326 | Hence, callbacks against **Promises** and **Mutation Observers** enter the **Microtask Queue**, where as all other callbacks enter the **Callback Queue**.
1327 | 
1328 | The **Callback Queue** is AKA the **Task Queue**.
1329 | 
1330 | **Starvation of Callback Queue**
1331 | 
1332 | Suppose we have callbacks lying in both the **Microtask Queue** and **Callback Queue**, and the **Microtask Queue** is adding more **Microtasks** to its queue. In such a scenario, the callbacks in the **Callback Queue** might never get a chance to get executed. This is known as **Starvation** of functions/tasks in the **Callback Queue**.
1333 | 
1334 | ---
1335 | 
1336 | ### JS Engine - Google's V8 Architecture
1337 | 
1338 | **JavaScript Runtime Environment** is like a container with capabilities required to execute JavaScript code. The **JavaScript Engine**, **APIs** to connect to the outer environment, **Event Loop**, **Callback Queue** and **Microtask Queue**, are all part of the **JavaScript Runtime Environment**. This Environment is not possible without the **JavaScript Engine**. Hence, the **JavaScript Engine** basically forms the heart of this environment.
1339 | 
1340 | Every web browser has a **JavaScript Runtime Environment**.
1341 | 
1342 | **Node.js** also provides a **JavaScript Runtime Environment**.
1343 | 
1344 | The **APIs** to connect to the outer environment differs from environment to environment. Also, the **APIs** which are common, like `setTimeout` for instance, are implemented differently for every **JavaScript Runtime Environment**.
1345 | 
1346 | Also, every browser uses it's own **JavaScript Engine**. **V8** for instance is used in Google Chrome, Node.js, Deno and V8.NET.
1347 | 
1348 | Anyone can create their own JavaScript Engine, the catch is to follow the protocols as portrayed in the **ECMAScript language standards**.
1349 | 
1350 | The world's first JavaScript engine was created by the creator of JavaScript himself, and has evolved to what we call today as **SpiderMonkey**, which is the JavaScript Engine used in Firefox.
1351 | 
1352 | **JS Engine is not a machine.**
1353 | 
1354 | JavaScript Engine is just like another program, written in a low-level language. For instance, V8 is written in C++.
1355 | 
1356 | **JS Engine Architecture**
1357 | 
1358 | The JavaScript Engine accepts the JavaScript code as input and this code goes through 3 major steps.
1359 | 
1360 | - Parsing
1361 | - Compilation
1362 | - Execution
1363 | 
1364 | During this **Parsing** phase, the code which we write is broken down into tokens.
1365 | 
1366 | We also have something called the **Syntax Parser**. The job of the **Syntax Parser** is to take the code and convert it to an **AST** (Abstract Syntax Tree). The **AST** is a detailed **JSON** which represents the tokens of our code in a tree-like structure.
1367 | 
1368 | This **AST** is then passed into the compilation phase.
1369 | 
1370 | Also, we can visualize **AST** using this tool -> [astexplorer.net](astexplorer.net)
1371 | 
1372 | The compilation and execution of JavaScript code goes hand in hand.
1373 | 
1374 | JavaScript has something called as **JIT** (Just In Time) **Compilation**.
1375 | 
1376 | JavaScript can behave as both an interpreted language and a compiled language, which actually depends on the **JavaScript Engine**.
1377 | 
1378 | When JavaScript was initially created, it _was supposed to be an interpreted language_.
1379 | 
1380 | But, in today's world of modern browsers, both interpretation and compilation goes hand in hand.
1381 | 
1382 | **JIT Compilation** uses best of the both worlds. It uses an interpreter as well as a compiler to execute JavaScript code.
1383 | 
1384 | Now, the **compilation** and **execution** steps go hand in hand.
1385 | 
1386 | After **parsing**, we received the **AST**. The **AST** goes to the interpreter and the interpreter converts the high-level code into byte code, which moves on to the **execution** step. Also, while it is doing so, the interpreter takes the help of the compiler to optimize the code. While the code gets interpreted line by line, the compiler also tries to optimize the code as much as it can. So, it's not a single phase process, but can happen in multiple phases. Every JavaScript Engine has its own algorithm of doing it. So, the job of the compiler is to optimize the code as much as it can on the runtime, that's why it's called **JIT** (Just In TIme) **Compilation**.
1387 | 
1388 | In some JavaScript Engines, there's something called as **AOT** (Ahead Of Time) **Compilation**. In that case the compiler basically take a piece of code, which is going to be executed later, and tries to optimize it as much as it can. And it also produces the byte code which goes to the **execution** phase.
1389 | 
1390 | This **execution** is not possible without 2 major components: the **Memory Heap** and the **Call Stack**.
1391 | 
1392 | The **Memory Heap** is where all the memory is stored. It is constantly in sync with the **Call Stack**, the garbage collector, and many other things. This is the place where all the data members (like variables and functions) are assigned memory. The garbage collector tries to free up memory space whenever possible.
1393 | 
1394 | The garbage collector works on the basis of the **Mark & Sweep Algorithm**.
1395 | 
1396 | Also, there are many forms of optimizations which a compiler does for the code. Some of which are:
1397 | 
1398 | - inlining
1399 | - copy elision
1400 | - inline caching
1401 | - etc...
1402 | 
1403 | All this information is very generic, as every JavaScript Engine has its own way of doing things.
1404 | 
1405 | At this instance, Google's V8 Engine is considered to be the fastest among all JavaScript Engines ever created.
1406 | 
1407 | The V8 Engine has an interpreter called **Ignition** and a compiler called **TurboFan**.
1408 | 
1409 | The V8 Engine Architecture can be visualized as follows:
1410 | 
1411 | ![v8-engine-architecture.png](https://i.ibb.co/VQW0Qd1/v8-engine-architecture.png)
1412 | 
1413 | Also, the garbage collector in the V8 Engine is called **Orinoco**, which uses the **Mark & Sweep Algorithm**.
1414 | 
1415 | It also has another garbage collector called **Oilpam**, which is used for a different purpose.
1416 | 
1417 | ---
1418 | 
1419 | ### Trust issues with `setTimeout()`
1420 | 
1421 | The `setTimeout()` has some issues. A `setTimeout()` with a timer of 5 seconds doesn't always exactly wait for 5 seconds.
1422 | 
1423 | This depends on the **Call Stack**.
1424 | 
1425 | Suppose our **Call Stack** is busy with the **GEC** (Global Execution Context), and hence is not vacant, then the **Event Loop** is unable to push any callback from the **Callback Queue**. This is also what we refer to as the **Concurrency Model** in JavaScript.
1426 | 
1427 | So, this forms the basis of **not blocking the main thread**.
1428 | 
1429 | We can block our main thread by simulating an environment by simply creating a while loop which would run for 10 seconds.
1430 | 
1431 | ```js
1432 | let startDate = new Date().getTime();
1433 | let endDate = startDate;
1434 | while (endDate < startDate + 10000) {
1435 |   endDate = new Date().getTime();
1436 | }
1437 | ```
1438 | 
1439 | It is also due to this **Concurrency Model** of JavaScript that we are able to perform asynchronous operations.
1440 | 
1441 | ---
1442 | 
1443 | ### Higher-Order Functions
1444 | 
1445 | A function which takes _another function as an argument or returns a function from it_, is known as a **Higher-Order Function**.
1446 | 
1447 | A proper example of an **Higher-Order Function** would be the following code snippet, where we are calculating area, circumference and diameter of 4 circles.
1448 | 
1449 | ```js
1450 | const radius = [3, 1, 2, 4];
1451 | 
1452 | const area = function (radius) {
1453 |   return Math.PI * radius * radius;
1454 | };
1455 | 
1456 | const circumference = function (radius) {
1457 |   return 2 * Math.PI * radius;
1458 | };
1459 | 
1460 | const diameter = function (radius) {
1461 |   return 2 * radius;
1462 | };
1463 | 
1464 | const calculate = function (arr, logic) {
1465 |   const output = [];
1466 |   for (let i = 0; i < arr.length; i++) {
1467 |     output.push(logic(arr[i]));
1468 |   }
1469 |   return output;
1470 | };
1471 | 
1472 | console.log(calculate(radius, area));
1473 | console.log(calculate(radius, circumference));
1474 | console.log(calculate(radius, diameter));
1475 | ```
1476 | 
1477 | So, as given in the above code, `area`, `circumference` and `diameter` are our callback functions, and `calculate` is our higher-order function.
1478 | 
1479 | **Pollyfill for map function in JavaScript**
1480 | 
1481 | `map` is a very common higher-order function.
1482 | 
1483 | `console.log(calculate(radius, area));`
1484 | 
1485 | is equivalent to
1486 | 
1487 | `console.log(radius.map(area));`
1488 | 
1489 | So, technically `calculate` in the above code block is like our implementation of `map`, although it's a miniature implementation.
1490 | 
1491 | Suppose we replace, the following snippet
1492 | 
1493 | ```js
1494 | const calculate = function (arr, logic) {
1495 |   const output = [];
1496 |   for (let i = 0; i < arr.length; i++) {
1497 |     output.push(logic(arr[i]));
1498 |   }
1499 |   return output;
1500 | };
1501 | ```
1502 | 
1503 | with the following
1504 | 
1505 | ```js
1506 | Array.prototype.calculate = function (logic) {
1507 |   const output = [];
1508 |   for (let i = 0; i < this.length; i++) {
1509 |     output.push(logic(this[i]));
1510 |   }
1511 |   return output;
1512 | };
1513 | ```
1514 | 
1515 | Now, we'll be able to use the `calculate` function in the same manner as we did with the `map` function, i.e., like this
1516 | 
1517 | ```js
1518 | console.log(radius.calculate(area));
1519 | ```
1520 | 
1521 | We just put the function `calculate` in the `Array.prototype`. This way the function `calculate` will now be available on all the arrays.
1522 | 
1523 | ---
1524 | 
1525 | ### `map`, `filter` & `reduce`
1526 | 
1527 | `map`, `filter` & `reduce` are higher-order functions in JavaScript.
1528 | 
1529 | #### `map`
1530 | 
1531 | The `map` function is basically used to transform an array. Transformation means to operate on each of the elements of the array and get a new array out of it.
1532 | 
1533 | We have to pass in a function inside `map`, a function which basically tells what function do we need, what transformation logic do we need to apply on each of the elements.
1534 | 
1535 | ```js
1536 | const arr = [5, 1, 3, 2, 6];
1537 | 
1538 | // returns double of a number
1539 | function double(x) {
1540 |   return x * 2;
1541 | }
1542 | 
1543 | // returns triple of a number
1544 | function triple(x) {
1545 |   return x * 3;
1546 | }
1547 | 
1548 | // returns binary of a number
1549 | function binary(x) {
1550 |   return x.toString(2);
1551 | }
1552 | 
1553 | console.log(arr.map(double));
1554 | console.log(arr.map(triple));
1555 | console.log(arr.map(binary));
1556 | ```
1557 | 
1558 | Now
1559 | 
1560 | ```js
1561 | arr.map(double);
1562 | ```
1563 | 
1564 | is equivalent to
1565 | 
1566 | ```js
1567 | arr.map(function double(x) {
1568 |   return x * 2;
1569 | });
1570 | ```
1571 | 
1572 | which in turn is equivalent to
1573 | 
1574 | ```js
1575 | arr.map((x) => {
1576 |   return x * 2;
1577 | });
1578 | ```
1579 | 
1580 | which, yet again, is equivalent to
1581 | 
1582 | ```js
1583 | arr.map((x) => x * 2);
1584 | ```
1585 | 
1586 | #### `filter`
1587 | 
1588 | The `filter` function is used to filter the values inside an array.
1589 | 
1590 | ```js
1591 | const arr = [5, 1, 3, 2 6];
1592 | 
1593 | function isOdd(x) {
1594 |   return x % 2;
1595 | }
1596 | 
1597 | function isEven(x) {
1598 |   return x % 2 === 0;
1599 | }
1600 | 
1601 | function greaterThan4(x) {
1602 |   return x > 4;
1603 | }
1604 | 
1605 | console.log(arr.filter(isOdd));
1606 | console.log(arr.filter(isEven));
1607 | console.log(arr.filter(greaterThan4));
1608 | ```
1609 | 
1610 | #### `reduce`
1611 | 
1612 | `reduce` function is basically used at a place where you have to take all the elements of an array and come up with a single value out of them.
1613 | 
1614 | It takes a callback function with 2 parameters, an **accumulator** and a **current**. When the `reduce` iterates over the elements, the **current** points to each of the elements of the array. The **accumulator** is used to accumulate the result of what we need to reduce out of these values. Also, the `reduce` function takes in a second parameter, which serves as the initial value of the **accumulator**.
1615 | 
1616 | Suppose we have an array of numbers and we want to find the sum of the elements. We can use the `reduce` function as follows.
1617 | 
1618 | ```js
1619 | const arr = [5, 1, 3, 2 6];
1620 | 
1621 | const output = arr.reduce(function (acc, curr) {
1622 |   acc = acc + curr;
1623 |   return acc;
1624 | }, 0);
1625 | ```
1626 | 
1627 | So, the first parameter to our `reduce` function is the callback, which has 2 parameters, the first one being the **accumulator** `acc` and the second being the **current** `curr`. This function has the accumulation logic, which would be used to reduce the result. Also, we have a second parameter to the `reduce` function, which is the initial value for our **accumulator**, `0` in this case.
1628 | 
1629 | Suppose we want to find out the max from our array. We can use `reduce` as follows.
1630 | 
1631 | ```js
1632 | const arr = [5, 1, 3, 2, 6];
1633 | 
1634 | const output = arr.reduce(function (max, curr) {
1635 |   if (curr > max) {
1636 |     max = curr;
1637 |   }
1638 |   return max;
1639 | }, 0);
1640 | ```
1641 | 
1642 | **[NOTE:** We've initialized our **accumulator** to `0` here since our array only has +ve values.**]**
1643 | 
1644 | #### Some real world use cases
1645 | 
1646 | Let's take the following array.
1647 | 
1648 | ```js
1649 | const users = [
1650 |   { firstName: "akshay", lastName: "saini", age: 26 },
1651 |   { firstName: "donald", lastName: "trump", age: 75 },
1652 |   { firstName: "elon", lastName: "musk", age: 50 },
1653 |   { firstName: "deepika", lastName: "padukone", age: 26 },
1654 | ];
1655 | ```
1656 | 
1657 | Suppose we want an array with full names. We can use the `map` function like shown below.
1658 | 
1659 | ```js
1660 | const output = users.map((x) = > x.firstName + " " + x.lastName);
1661 | ```
1662 | 
1663 | Suppose we want to create an object with the age as the key and its value as the frequency of the number of people with that age. In such a case, we case use the `reduce` as follows.
1664 | 
1665 | ```js
1666 | // acc = {26: 2, 50: 1, 75: 1}
1667 | const output = users.reduce(function (arr, curr) {
1668 |   if (acc[curr.age]) {
1669 |     acc[curr.age] = ++acc[curr.age];
1670 |   } else {
1671 |     acc[curr.age] = 1;
1672 |   }
1673 |   return acc;
1674 | }, {});
1675 | ```
1676 | 
1677 | Now, suppose we want the first names of all people with age < 30. We can do something like this.
1678 | 
1679 | ```js
1680 | const output = users.filter((x) => x.age < 30).map((x) => x.firstName);
1681 | ```
1682 | 
1683 | #### Challenge
1684 | 
1685 | Instead of chaining the `filter` and `map` function to achieve the above result, use only `reduce`.
1686 | 
1687 | **Solution**
1688 | 
1689 | ```js
1690 | const output = users.reduce(function (acc, curr) {
1691 |   if (curr.age < 30) {
1692 |     acc.push(curr.firstName);
1693 |   }
1694 |   return acc;
1695 | }, []);
1696 | ```
1697 | 
1698 | ---
1699 | 
1700 | SOURCE: [Namaste 🙏 JavaScript by Akshay Saini]
1701 | 


--------------------------------------------------------------------------------