The ten Most Frequent JavaScript Points Builders Face

Editor’s observe: This text was up to date by our editorial staff on July 19, 2022. It has been modified to incorporate latest sources and to align with our present editorial requirements.

At the moment, JavaScript is on the core of just about all fashionable internet purposes. That’s why JavaScript points, and discovering the errors that trigger them, are on the forefront for internet builders.

Highly effective JavaScript-based libraries and frameworks for single web page utility (SPA) growth, graphics and animation, and server-side JavaScript platforms are nothing new. JavaScript has really change into ubiquitous on the earth of internet app growth and is due to this fact an more and more vital talent to grasp.

At first, JavaScript could seem fairly easy. And certainly, to construct fundamental JavaScript performance into an internet web page is a reasonably simple activity for any skilled software program developer, even when they’re new to JavaScript. But the language is considerably extra nuanced, highly effective, and sophisticated than one would initially be led to consider. Certainly, lots of JavaScript’s subtleties result in quite a lot of widespread issues that hold it from working—10 of which we talk about right here—which might be vital to pay attention to and keep away from in a single’s quest to change into a grasp JavaScript developer.

JavaScript Difficulty #1: Incorrect References to this

There’s no scarcity of confusion amongst JavaScript builders concerning JavaScript’s this key phrase.

As JavaScript coding methods and design patterns have change into more and more refined through the years, there’s been a corresponding improve within the proliferation of self-referencing scopes inside callbacks and closures, that are a reasonably widespread supply of “this/that confusion” inflicting JavaScript points.

Take into account this instance code snippet:

Recreation.prototype.restart = operate () {
    this.clearLocalStorage();
    this.timer = setTimeout(operate() {
    this.clearBoard();    // What's "this"?
    }, 0);
};

Executing the above code leads to the next error:

Uncaught TypeError: undefined is just not a operate

Why? It’s all about context. The rationale you get the above error is as a result of, while you invoke setTimeout(), you’re really invoking window.setTimeout(). In consequence, the nameless operate being handed to setTimeout() is being outlined within the context of the window object, which has no clearBoard() methodology.

A standard, old-browser-compliant answer is to easily save your reference to this in a variable that may then be inherited by the closure; e.g.:

Recreation.prototype.restart = operate () {
    this.clearLocalStorage();
    var self = this;   // Save reference to 'this', whereas it is nonetheless this!
    this.timer = setTimeout(operate(){
    self.clearBoard();    // Oh OK, I do know who 'self' is!
    }, 0);
};

Alternatively, in newer browsers, you need to use the bind() methodology to cross within the correct reference:

Recreation.prototype.restart = operate () {
    this.clearLocalStorage();
    this.timer = setTimeout(this.reset.bind(this), 0);  // Bind to 'this'
};

Recreation.prototype.reset = operate(){
    this.clearBoard();    // Ahhh, again within the context of the correct 'this'!
};

JavaScript Difficulty #2: Pondering There Is Block-level Scope

As mentioned in our JavaScript Hiring Information, a standard supply of confusion amongst JavaScript builders (and due to this fact a standard supply of bugs) is assuming that JavaScript creates a brand new scope for every code block. Though that is true in lots of different languages, it’s not true in JavaScript. Take into account, for instance, the next code:

for (var i = 0; i < 10; i++) {
    /* ... */
}
console.log(i);  // What is going to this output?

When you guess that the console.log() name would both output undefined or throw an error, you guessed incorrectly. Consider it or not, it can output 10. Why?

In most different languages, the code above would result in an error as a result of the “life” (i.e., scope) of the variable i could be restricted to the for block. In JavaScript, although, this isn’t the case and the variable i stays in scope even after the for loop has accomplished, retaining its final worth after exiting the loop. (This habits is thought, by the way, as variable hoisting.)

Assist for block-level scopes in JavaScript is accessible by way of the let key phrase. The let key phrase has been broadly supported by browsers and back-end JavaScript engines like Node.js for years now..

If that’s information to you, it’s price taking the time to learn up on scopes, prototypes, and extra.

JavaScript Difficulty #3: Creating Reminiscence Leaks

Reminiscence leaks are virtually inevitable JavaScript points in case you’re not consciously coding to keep away from them. There are quite a few methods for them to happen, so we’ll simply spotlight a few their extra widespread occurrences.

Reminiscence Leak Instance 1: Dangling References to Defunct Objects

Take into account the next code:

var theThing = null;
var replaceThing = operate () {
  var priorThing = theThing;  // Maintain on to the prior factor
  var unused = operate () {
    // 'unused' is the one place the place 'priorThing' is referenced,
    // however 'unused' by no means will get invoked
    if (priorThing) {
      console.log("hello");
    }
  };
  theThing = {
    longStr: new Array(1000000).be part of('*'),  // Create a 1MB object
    someMethod: operate () {
      console.log(someMessage);
    }
  };
};
setInterval(replaceThing, 1000);    // Invoke `replaceThing' as soon as each second

When you run the above code and monitor reminiscence utilization, you’ll discover that you simply’ve received a major reminiscence leak, leaking a full megabyte per second! And even a guide Rubbish Collector (GC) doesn’t assist. So it appears like we’re leaking longStr each time replaceThing is named. However why?

Reminiscence leaks are virtually inevitable JavaScript points in case you’re not consciously coding to keep away from them.

Let’s study issues in additional element:

Every theThing object comprises its personal 1MB longStr object. Each second, once we name replaceThing, it holds on to a reference to the prior theThing object in priorThing. However we nonetheless wouldn’t assume this is able to be an issue, since every time by means of, the beforehand referenced priorThing could be dereferenced (when priorThing is reset by way of priorThing = theThing;). And furthermore, is barely referenced in the primary physique of replaceThing and within the operate unused which is, in reality, by no means used.

So once more we’re left questioning why there’s a reminiscence leak right here.

To know what’s occurring, we have to higher perceive the internal workings of JavaScript. The standard means that closures are carried out is that each operate object has a hyperlink to a dictionary-style object representing its lexical scope. If each features outlined inside replaceThing really used priorThing, it could be vital that they each get the identical object, even when priorThing will get assigned to time and again, so each features share the identical lexical atmosphere. However as quickly as a variable is utilized by any closure, it leads to the lexical atmosphere shared by all closures in that scope. And that little nuance is what results in this gnarly reminiscence leak.

Reminiscence Leak Instance 2: Round References

Take into account this code fragment:

operate addClickHandler(component) {
    component.click on = operate onClick(e) {
        alert("Clicked the " + component.nodeName)
    }
}

Right here, onClick has a closure that retains a reference to component (by way of component.nodeName). By additionally assigning onClick to component.click on, the round reference is created; i.e.: component → onClick → component → onClick → component…

Apparently, even when component is faraway from the DOM, the round self-reference above would stop component and onClick from being collected, and therefore, a reminiscence leak.

Avoiding Reminiscence Leaks: The Necessities

JavaScript’s reminiscence administration (and, particularly, rubbish assortment) is essentially based mostly on the notion of object reachability.

The next objects are assumed to be reachable and are often known as “roots”:

• Objects referenced from anyplace within the present name stack (that’s, all native variables and parameters within the features at present being invoked, and all of the variables within the closure scope)
• All international variables

Objects are saved in reminiscence not less than so long as they’re accessible from any of the roots by means of a reference, or a series of references.

There’s a Rubbish Collector within the browser that cleans reminiscence occupied by unreachable objects; in different phrases, objects will likely be faraway from reminiscence if and provided that the GC believes that they’re unreachable. Sadly, it’s pretty simple to finish up with defunct “zombie” objects which might be not in use however that the GC nonetheless thinks are “reachable.”

JavaScript Difficulty #4: Confusion About Equality

One of many conveniences in JavaScript is that it’s going to routinely coerce any worth being referenced in a boolean context to a boolean worth. However there are instances the place this may be as complicated as it’s handy. A number of the following, for instance, have been identified to be troublesome for a lot of a JavaScript developer:

// All of those consider to 'true'!
console.log(false == '0');
console.log(null == undefined);
console.log(" trn" == 0);
console.log('' == 0);

// And these do too!
if ({}) // ...
if ([]) // ...

With regard to the final two, regardless of being empty (which could lead one to consider that they’d consider to false), each {} and [] are in reality objects and any object will likely be coerced to a boolean worth of true in JavaScript, in line with the ECMA-262 specification.

As these examples exhibit, the foundations of kind coercion can typically be clear as mud. Accordingly, until kind coercion is explicitly desired, it’s sometimes finest to make use of === and !== (reasonably than == and !=), in order to keep away from any unintended unwanted side effects of kind coercion. (== and != routinely carry out kind conversion when evaluating two issues, whereas === and !== do the identical comparability with out kind conversion.)

And fully as a sidepoint—however since we’re speaking about kind coercion and comparisons—it’s price mentioning that evaluating NaN with something (even NaN!) will all the time return false. You due to this fact can not use the equality operators (==, ===, !=, !==) to find out whether or not a price is NaN or not. As a substitute, use the built-in international isNaN() operate:

console.log(NaN == NaN);    // False
console.log(NaN === NaN);   // False
console.log(isNaN(NaN));    // True

JavaScript Difficulty #5: Inefficient DOM Manipulation

JavaScript makes it comparatively simple to govern the DOM (i.e., add, modify, and take away parts), however does nothing to advertise doing so effectively.

A standard instance is code that provides a collection of DOM Components separately. Including a DOM component is an costly operation. Code that provides a number of DOM parts consecutively is inefficient and certain to not work effectively.

One efficient different when a number of DOM parts have to be added is to make use of doc fragments as a substitute, thereby bettering effectivity and efficiency.

For instance:

var div = doc.getElementsByTagName("my_div");
	
var fragment = doc.createDocumentFragment();

for (var e = 0; e < elems.size; e++) {  // elems beforehand set to checklist of parts
    fragment.appendChild(elems[e]);
}
div.appendChild(fragment.cloneNode(true));

Along with the inherently improved effectivity of this method, creating hooked up DOM parts is pricey, whereas creating and modifying them whereas indifferent after which attaching them yields a lot better efficiency.

JavaScript Difficulty #6: Incorrect Use of Perform Definitions Inside for Loops

Take into account this code:

var parts = doc.getElementsByTagName('enter');
var n = parts.size;    // Assume we have now 10 parts for this instance
for (var i = 0; i < n; i++) {
    parts[i].onclick = operate() {
        console.log("That is component #" + i);
    };
}

Based mostly on the above code, if there have been 10 enter parts, clicking any of them would show “That is component #10”! It is because, by the point onclick is invoked for any of the weather, the above for loop can have accomplished and the worth of i will already be 10 (for all of them).

Right here’s how we are able to appropriate the aforementioned issues with JavaScript to realize the specified habits:

var parts = doc.getElementsByTagName('enter');
var n = parts.size;    // Assume we have now 10 parts for this instance
var makeHandler = operate(num) {  // Outer operate
     return operate() {   // Inside operate
         console.log("That is component #" + num);
     };
};
for (var i = 0; i < n; i++) {
    parts[i].onclick = makeHandler(i+1);
}

On this revised model of the code, makeHandler is instantly executed every time we cross by means of the loop, every time receiving the then-current worth of i+1 and binding it to a scoped num variable. The outer operate returns the internal operate (which additionally makes use of this scoped num variable) and the component’s onclick is about to that internal operate. This ensures that every onclick receives and makes use of the correct i worth (by way of the scoped num variable).

JavaScript Difficulty #7: Failure to Correctly Leverage Prototypal Inheritance

A surprisingly excessive share of JavaScript builders fail to completely perceive, and due to this fact to completely leverage, the options of prototypal inheritance.

Right here’s a easy instance. Take into account this code:

BaseObject = operate(title) {
    if (typeof title !== "undefined") {
        this.title = title;
    } else {
        this.title="default"
    }
};

Appears pretty simple. When you present a reputation, use it, in any other case set the title to ‘default’. As an example:

var firstObj = new BaseObject();
var secondObj = new BaseObject('distinctive');

console.log(firstObj.title);  // -> Ends in 'default'
console.log(secondObj.title); // -> Ends in 'distinctive'

However what if we had been to do that:

delete secondObj.title;

We’d then get:

console.log(secondObj.title); // -> Ends in 'undefined'

However wouldn’t it’s nicer for this to revert to ‘default’? This will simply be completed, if we modify the unique code to leverage prototypal inheritance, as follows:

BaseObject = operate (title) {
    if(typeof title !== "undefined") {
        this.title = title;
    }
};

BaseObject.prototype.title="default";

With this model, BaseObject inherits the title property from its prototype object, the place it’s set (by default) to 'default'. Thus, if the constructor is named and not using a title, the title will default to default. And equally, if the title property is faraway from an occasion of BaseObject, the prototype chain will then be searched and the title property will likely be retrieved from the prototype object the place its worth remains to be 'default'. So now we get:

var thirdObj = new BaseObject('distinctive');
console.log(thirdObj.title);  // -> Ends in 'distinctive'

delete thirdObj.title;
console.log(thirdObj.title);  // -> Ends in 'default'

JavaScript Difficulty #8: Creating Incorrect References to Occasion Strategies

Let’s outline a easy object, and create an occasion of it, as follows:

var MyObject = operate() {}
	
MyObject.prototype.whoAmI = operate() {
    console.log(this === window ? "window" : "MyObj");
};

var obj = new MyObject();

Now, for comfort, let’s create a reference to the whoAmI methodology, presumably so we are able to entry it merely by whoAmI() reasonably than the longer obj.whoAmI():

var whoAmI = obj.whoAmI;

And simply to make sure all the things appears copacetic, let’s print out the worth of our new whoAmI variable:

console.log(whoAmI);

Outputs:

operate () {
    console.log(this === window ? "window" : "MyObj");
}

Okay, cool. Seems to be tremendous.

However now, take a look at the distinction once we invoke obj.whoAmI() vs. our comfort reference whoAmI():

obj.whoAmI();  // Outputs "MyObj" (as anticipated)
whoAmI();      // Outputs "window" (uh-oh!)

What went unsuitable? After we did the project var whoAmI = obj.whoAmI;, the brand new variable whoAmI was being outlined within the international namespace. In consequence, its worth of this is window, not the obj occasion of MyObject!

Thus, if we actually have to create a reference to an current methodology of an object, we have to make sure to do it inside that object’s namespace, to protect the worth of this. A technique of doing this is able to be as follows:

var MyObject = operate() {}
	
MyObject.prototype.whoAmI = operate() {
    console.log(this === window ? "window" : "MyObj");
};

var obj = new MyObject();
obj.w = obj.whoAmI;   // Nonetheless within the obj namespace

obj.whoAmI();  // Outputs "MyObj" (as anticipated)
obj.w();       // Outputs "MyObj" (as anticipated)

JavaScript Difficulty #9: Offering a String because the First Argument to setTimeout or setInterval

For starters, let’s be clear on one thing right here: Offering a string as the primary argument to setTimeout or setInterval is not itself a mistake per se. It’s completely reliable JavaScript code. The problem right here is extra considered one of efficiency and effectivity. What isn’t defined is that in case you cross in a string as the primary argument to setTimeout or setInterval, it will likely be handed to the operate constructor to be transformed into a brand new operate. This course of might be gradual and inefficient, and isn’t mandatory.

The choice to passing a string as the primary argument to those strategies is to as a substitute cross in a operate. Let’s check out an instance.

Right here, then, could be a reasonably typical use of setInterval and setTimeout, passing a string as the primary parameter:

setInterval("logTime()", 1000);
setTimeout("logMessage('" + msgValue + "')", 1000);

The higher selection could be to cross in a operate because the preliminary argument; e.g.:

setInterval(logTime, 1000);   // Passing the logTime operate to setInterval
	
setTimeout(operate() {       // Passing an nameless operate to setTimeout
    logMessage(msgValue);     // (msgValue remains to be accessible on this scope)
}, 1000);

JavaScript Difficulty #10: Failure to Use “Strict Mode”

As defined in our JavaScript Hiring Information, “strict mode” (i.e., together with 'use strict'; firstly of your JavaScript supply information) is a strategy to voluntarily implement stricter parsing and error dealing with in your JavaScript code at runtime, in addition to making it safer.

Whereas, admittedly, failing to make use of strict mode is just not a “mistake” per se, its use is more and more being inspired and its omission is more and more turning into thought of dangerous type.

Listed below are some key advantages of strict mode:

• Makes debugging simpler. Code errors that will in any other case have been ignored or would have failed silently will now generate errors or throw exceptions, alerting you sooner to issues with JavaScript in your codebase and directing you extra rapidly to their supply.
• Prevents unintentional globals. With out strict mode, assigning a price to an undeclared variable routinely creates a world variable with that title. This is likely one of the most typical JavaScript errors. In strict mode, trying to take action throws an error.
• Eliminates this coercion. With out strict mode, a reference to a this worth of null or undefined is routinely coerced to the worldwide. This will trigger many irritating bugs. In strict mode, referencing a this worth of null or undefined throws an error.
• Disallows duplicate property names or parameter values. Strict mode throws an error when it detects a reproduction named property in an object (e.g., var object = {foo: "bar", foo: "baz"};) or a reproduction named argument for a operate (e.g., operate foo(val1, val2, val1){}), thereby catching what is sort of actually a bug in your code that you simply may in any other case have wasted a lot of time monitoring down.
• Makes eval() safer. There are some variations in the way in which eval() behaves in strict mode and in nonstrict mode. Most importantly, in strict mode, variables and features declared inside an eval() assertion are not created within the containing scope. (They are created within the containing scope in nonstrict mode, which can be a standard supply of issues with JavaScript.)
• Throws error on invalid use of delete. The delete operator (used to take away properties from objects) can’t be used on nonconfigurable properties of the thing. Nonstrict code will fail silently when an try is made to delete a nonconfigurable property, whereas strict mode will throw an error in such a case.

Mitigating JavaScript Points With a Smarter Method

As is true with any expertise, the higher you perceive why and the way JavaScript works and doesn’t work, the extra strong your code will likely be and the extra you’ll be capable to successfully harness the true energy of the language. Conversely, lack of correct understanding of JavaScript paradigms and ideas is certainly the place many JavaScript issues lie.

Totally familiarizing your self with the language’s nuances and subtleties is the best technique for bettering your proficiency and growing your productiveness. Avoiding many widespread JavaScript errors will assist when your JavaScript is just not working.

---

Additional Studying on the Toptal Engineering Weblog: