1. Event delegation
So you may want to simply do something like the following to attach event listeners to the elements:
While this does technically work, the problem is that you are attaching an event listener to every single item individually. This is fine for 4 elements, but what if someone adds 10,000 items (they may have a lot of things to do…) to their Todo list? Then your function will create 10,000 separate event listeners and attach them to the DOM — this isn’t very efficient.
In an interview it would be best to first ask the interviewer how many items can a Todo list hold, i.e. what is the maximum number of elements the user can enter? If it can never be more than 10 for example, then the above code would work fine, but if there is no limit on the number of items the user can enter, then a more efficient solution may be required.
If your application may end up having hundreds or thousands of event listeners, the more efficient solution is to actually attach one event listener to the whole container, and then be able to access the item that was actually clicked. This is called event delegation and it is much more efficient than attaching separate event handlers. Below is the code for event delegation:
2. Closure within a loop
Closures are sometimes brought up in an interview so that the interviewer can gauge how familiar you are with the language and if you know how and for what reason to implement a closure. A closure is basically when an inner function has access to variables outside of its scope. Closures can be used for things like implementing privacy and creating function factories. A common interview question regarding the use of closures is something like the following:
Write a function that will loop through a list of integers and print the index of each element after a 3 second delay.
A common (incorrect) implementation I’ve seen for this problem looks something like this:
If you run this you’ll see that you actually get the 4 printed out every time instead of the expected 0, 1, 2, 3 after a 3 second delay.
There are some browser events that can fire many times within a short timespan very quickly, such as resizing a window or scrolling down a page. If you attach an event listener to the window scroll event for example, and the user continuously scrolls down the page very quickly, your event may fire thousands of times within the span of 3 seconds. This may start causing some serious performance issues!
If you are discussing building an application in an interview and events like scrolling, window resizing, or key pressing come up, make sure to mention debouncing and/or throttling as a way to improve page speed and performance. A real example taken from this guest post on css-tricks:
In 2011, an issue popped up on the Twitter website: when you were scrolling down your Twitter feed, it became slow and unresponsive. John Resig published a blog post about the problem where it was explained how bad of an idea it is to directly attach expensive functions to the
The function above, when wrapped around an event, will execute only after a certain amount of time has elapsed. You would use the function like so:
Throttling is another technique that is similar to debouncing except that instead of waiting for some time to pass by before calling a function, throttling just spreads out the function calls via some time interval. So if an event occurs 10 times within 100 milliseconds, with throttling you can spread out each of the function calls to be executed once every 2 seconds for example instead of all firing within 100 milliseconds.
For more information on debouncing and throttling the following articles and tutorials may be helpful: