Added Callbacks, Event Listeners, and the Event Loop

avinashyadav16 · avinashyadav16 · commit c422fa092c4a · 2025-06-07T22:41:32.000+05:30
diff --git a/17_Callbacks_And_EventListeners.md b/17_Callbacks_And_EventListeners.md
@@ -0,0 +1,107 @@
+# CHAPTER 17: Callbacks and Event Listeners
+
+**Callback Function :** Functions are first class citizens i.e. take a function `A` and pass it to another function `B`. Here, `A` is a callback function.(Function that is passed on as argument to another function is called callback function.)
+
+```javascript
+function B(A) {}
+
+B(function A() {});
+```
+
+- JS is a **synchronous** and **single threaded** language e.g. It can do only one thing at a time and in a specific order. But due to callbacks, we can do async things in JS.
+
+- The callback functions are very powerful in JS as they give the access to whole asynchronous world into synchronous single threaded language.
+
+- So, callback functions gives JS the power of asynchronosity.
+
+> `setTimeout(function () {}, 1000)` -> here the anonymous function is a callback function as it is passed to setTimeout and called sometime later in code after certain time (here 1000ms).
+
+- This is how we do async things. JS is a sync language, but it doesn't wait 1 sec for setTimeout to finish before going to code below it. It stores the function, attaches timer and goes down the code.
+
+```javascript
+setTimeout(function () {
+  console.log("timer");
+}, 5000);
+
+function x(y) {
+  console.log("x");
+
+  y();
+}
+
+x(function y() {
+  console.log("y");
+});
+```
+
+OUTPUT
+
+    x
+
+    y
+
+    timer
+
+- 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 i.e. setTimeout
+- All 3 functions are executed through call stack. If any operation blocks the call stack, its called **blocking the main thread**
+- 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_.
+- **Always use async for functions that take time e.g. setTimeout**
+
+- JS has just only one call stack and we can call it main thread. So, everything that is executed on our page, is executed throught the call stack only.
+
+- And if any operation blocks the call stack then that is called as blocking the main thread.
+
+## **Event Listener**
+
+- When we create a button in HTML and attack a clickListener in JS:
+
+_in index.html_
+
+```html
+<button id="clickMe">Click Me!</button>
+```
+
+_in index.js_
+
+```javascript
+document.getElementById("clickMe").addEventListener("click", function xyz() {
+  //when event click occurs, this callback function is called into callstack
+  console.log("Button clicked");
+});
+```
+
+Suppose we want to increase count by 1 each time button clicked.
+
+- Use global variable (not good as anyone can change it)
+
+```javascript
+let count = 0;
+
+document.getElementById("clickMe").addEventListener("click", function xyz() {
+  console.log("Button clicked", ++count);
+});
+```
+
+- Use closures for data abstraction
+
+```javascript
+function attachEventList() {
+  //creating new function for closure
+  let count = 0;
+
+  document.getElementById("clickMe").addEventListener("click", function xyz() {
+    console.log("Button clicked", ++count); //now callback function forms closure with outer scope(count)
+  });
+}
+
+attachEventList();
+```
+
+#### Garbage Collection and removeEventListeners
+
+- Event listeners are heavy, that means they take up memory.
+- 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 when it may need _count_ again.
+- Event listeners can also invoke closures with scope.
+- Event listeners consume a lot of memory which can potentially slow down the website therefore it is good practice to remove if it is not used.
+- **So we remove event listeners when we don't need them (garbage collected)**
+- onClick, onHover, onScroll all in a page can slow it down heavily.
diff --git a/18_Async_And_EventLoops.md b/18_Async_And_EventLoops.md
@@ -0,0 +1,133 @@
+# CHAPTER 18: Asynchronous JS and Event Loops
+
+- JS is synchronous single threaded language. It has one call stack and all the code of JS is executed inside this call stack. It can only do one thing at a time. This call stack is present inside the JS Engine.
+
+> 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
+
+**Browser has JS Engine which has Call Stack which has Global exec context, local exec context etc**
+
+- But browser has many other _superpowers_ - Local storage space, Timer, place to enter URL, Bluetooth access, Geolocation access and so on
+- Now JS needs some way to connect the callstack with all these superpowers. This is done using **Web APIs**
+
+### WebAPIs
+
+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.
+
+> setTimeout(), DOM APIs, fetch(), localstorage, console (yes, even console.log is not JS!!), location and so many more..
+
+- setTimeout() : Timer function
+- DOM APIs : eg.Document.xxxx ; Used to access HTML `<html><script><body>.....` DOM tree. (Document Object Manipulation)
+- fetch() : Used to make connection with external servers eg. Netflix servers etc.
+
+  We get all these inside call stack through _global object_ ie. **window**
+
+- Use window keyword like : window.setTimeout(), window.localstorage, window.console.log() to log something inside console.
+- 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
+
+### Workflow
+
+```javascript
+// First a GEC is created and put inside call stack.
+console.log("Start"); // this calls the console web api (through window) which in turn actually modifies values in console.
+
+setTimeout(function cb() {
+  //this calls the setT web api which gives access to timer feature. It stores the callback cb() and starts timer.
+  console.log("Callback");
+}, 5000);
+
+console.log("End"); // calls console api and logs in console window. After this GEC pops from call stack.
+```
+
+- While all this is happening, the timer is constantly ticking. After it becomes `0`, the callback `cb()` has to run.
+- 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**
+
+### Event Loops and Callback Queue
+
+- `cb()` cannot simply directly go to callstack to be execeuted. It goes through the callback queue when timer expires.
+- Event loop checks the callback queue, and if it has element puts it into call stack. It is a _gate keeper_.
+- Now `cb()` in callstack is run. Console API is used and log printed
+
+Final console output:
+
+    Start
+
+    End
+
+    Callback
+
+### Same happens for any other event as well (Click, Hover etc). This is the basic workflow.
+
+```javascript
+console.log("Start");
+document.getElementById("btn").addEventListener("click", function cb() {
+  // cb() registered inside webapi environment and event(click) attached to it. ie.
+  // REGISTERING CALLBACK AND ATTACHING EVENT TO IT.
+  console.log("Callback");
+});
+
+console.log("End"); // calls console api and logs in console window. After this GEC pops from call stack.
+```
+
+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 some day) until explicitly removed, or the browser is closed.
+
+### Why need callback queue?
+
+- 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.
+- Event loop sees if call stack is empty/has space and whether callback queue is not empty(6 elements here).
+- Elements of callback queue popped off, put in callstack, executed and then popped off from call stack.
+
+### fetch() works a bit different than the rest
+
+```javascript
+console.log("Start");
+
+// this calls the console web api (through window) which in turn actually modifies values in console.
+
+setTimeout(function cbT() {
+  console.log("CB Timeout");
+}, 5000);
+
+fetch("https://api.netflix.com").then(function cbF() {
+  console.log("CB Netflix");
+});
+
+console.log("End");
+```
+
+- Same steps for everything before `fetch()` in above code.
+- fetch registers `cbF` into webapi environment along with existing `cbT`.
+- `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.
+- fetch requests data from Netflix servers, and get data back and now `cbF` ready to be executed.
+  **We have something called a Microtask Queue**
+- It is exactly same as Callback queue, but it has higher priority. Functions in Microtask `Q` are executed earlier than Callback `Q`.
+- `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 Callback Queue to enter Call Stack.
+
+- In console, first _Start_ and _End_ are printed in console. First `cbF` goes in callstack and "CB Netflix" is printed. `cbF` popped from callstack
+- Next `cbT` is removed from callback Q, put in Call Stack, "CB Timeout" is printed, and `cbT` removed from callstack.
+
+### What enters the Microtask Queue ?
+
+- All the callback functions that come through _promises_ go in microtask Q.
+- **Mutation Observer:** Keeps on checking whether there is mutation in DOM tree or not, and if there, then it execeutes some callback function.
+- Callback functions that come through _promises and mutation observer_ go inside Microtask Queue.
+- All the rest goes inside **Callback Queue aka Task Queue**
+
+- 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**
+
+### Some Important Questions
+
+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.
+
+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.
+
+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.
+
+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.
