简体   繁体   中英

How JavaScript DOM events are continuously handled even if they are inside a function

lets imagine a scenario

function clickEventCheck() {

    document.querySelector('#some-id').addEventListener('click', () => {

             console.log("The button is clicked");
      });
}

clickEventCheck();

Now I get that for the first time the 'clickEventCheck' function is getting called and we can handle the click event. But now the execution stack is empty so how the event handler line of code which is inside our function(which has returned) still gets executed every time we click the button?

When the function is called click listener is added to the element with id some-id . So, whenever you click the element, the code inside the callback function gets executed.

Until and unless the click listener is not explicitly removed from the element i:e element with id some-id , it will listen to click events.

 function clickHandler() { console.log('The button is clicked'); } function clickEventCheck() { document.querySelector('#some-id').addEventListener('click', clickHandler); } clickEventCheck(); document.querySelector('.remove').addEventListener('click', () => { document.querySelector('#some-id').removeEventListener('click', clickHandler); });
 <button id="some-id">Click Me</button> <button class="remove">Remove Click Listener</button>

JavaScript is doing more than just executing your code sequentially, line by line. In the background there is also something running called the event loop . This frequently checks another stack to see if any other instructions are there and if so runs those, starting additional chains of execution called frames.

Two nice properties of those frames is that they will keep running as long as they can so you don't have to reason about random switching between them, and they don't block, so once a frame can't execute any further, the engine will look for another frame to execute from the stack. This also leads to smooth switching between frames provided you are not doing CPU-heavy execution (which isn't normally what JavaScript's used for).

Practically what might happen is one frame (frame A) makes an I/O request, and provides a callback function when it does so. Frame A then runs out of code to execute and the event loop picks the next frame (frame B) to run. In the background, when the I/O request completes the callback function will be added to the stack—and then when frame B runs out of code, the event loop can pick up that callback and execute it in yet another frame. The same process could apply for a button click, a mouse move, or any asynchronous process you can get the computer to do.

In this way a large number of I/O connections can be smoothly handled simultaneously and this is a big selling point of NodeJs.

A lot of callbacks can get messy quickly and that's why there also exists concepts like Promises and async functions, which are topics for another day.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM