Using Classes in JavaScript: 3 Mistakes That You're Most Likely to Make & How to Avoid Them

Using Classes in JavaScript: 3 Mistakes That You're Most Likely to Make & How to Avoid Them

Since 2015, the question: "Why are there no classes in JavaScript?", that used to be on any developer's lips, is no longer relevant. Classes did make their entrance in ECMAScript 2015 (ES6). And yet: many developers still don't know how they operate. Moreover, they don't perceive JS classes as "real" classes. This is why, when using classes in JavaScript, they make involuntary mistakes that lead to subtle bugs in their apps.

  • “But which are those errors that are most likely to occur when I mishandle JavaScript classes?”
  • “And how can I avoid them or at least get them quickly fixed?"

For, obviously, you can't prevent errors from occurring if you don't really know what mistakes you're making, right?

Therefore, here are the 3 most common mistakes that you, too, are likely to make when working with classes in JavaScript:

More About JavaScript Classes: Are They, Indeed, "Real" Classes?

Here's a simple, yet clear-enough definition for classes in JavaScript:

They're basically syntactical sugar over prototypes (JS's prototype-based inheritance), with a much simpler and clearer syntax. 

And it goes without saying that such a syntax bubbles up to the developer experience: you get to write less (and cleaner) code when creating objects and dealing with inheritance issues.

“But are JavaScript classes “real” classes?” is another question “tormenting” plenty of JS programmers out there. 

So, let me shed some light on this “dilemma”:

There are 2 minor differences between JS classes (or JS class-like objects) and so called “real” classes:

  1. when using classes in JavaScript you need to append static attributes once you've defined your classes
  2. also, there are no private members

Besides that, they do serve the same practical purpose and behave like any other class-based system.

Furthermore, I feel like stressing the fact that JavaScript classes DO NOT bring any new object-oriented inheritance model.

Mistake No. 1: Not Running Your JavaScript Code in "Strict Mode"

Strict mode issues will inevitably lead to errors in your app.

But you must be asking yourself right now: “What's the point? Why is JavaScript code (meaning the body of a class —  that section within the curly brackets) executed in strict mode?”

  1. because the strict mode “challenges” classes to throw some of the once silent errors
  2. because it runs code in a stricter syntax and thus solves some of the old inconsistencies in JavaScript

“When do errors occur, more precisely?”

When you overlook to execute your JavaScript code — the constructor method, the prototype method, the static method, plus other functions —  in strict mode!

Note: another way to define your JavaScript classes is using class expressions, which can be either named or unnamed. Do keep in mind, though, that duplicating a parameter name will not be “permitted”, due to strict mode. Doing so will automatically lead to... errors.

Mistake No. 2: Not Handling Subclasses Properly

At some point, while using classes in Javascript, you might need to turn a certain class into another one's child. Or its subclass, if you prefer.

The proper way to do it?

Using the “extends” keyword in “class expression” or in “class declaration”. Its role is to set up single-ancestor class taxonomies.

Note: if you have a constructor method in your child class, the right way to do it is to call “super()” first, then the “this” keyword. 

Word of caution: do keep in mind that JavaScript classes do not extend non-constructible objects. In this case, you can use the Object.setPrototypeOf() method to safely inherit from a regular object!

Mistake No. 3: Not Declaring Your JS Classes Before Using Them

… which leads to hoisting issues.

First of all, let's try to define “hoisting”:

It's a JavaScript inherent mechanism where every variable and function declaration gets moved to the top of its present scope (be it global or local) before execution.

Clear enough?

Furthermore, hoisting is that JS characteristic that sets function declarations (and JS classes are perceived as “special functions”) apart from class declarations: the latter aren't hoisted.

So, how do you prevent hoisting issues from occurring when using classes in JavaScript?

You first declare your class — using the “class” keyword accompanied by the name of the class — and it's only then that you access it. Otherwise, your code will throw a ReferenceError “at you”.

Afterword: Using Classes in JavaScript Remains a Best Practice

Undoubtedly! For even though using classes in JavaScript does have its “gotchas!”, now that you know them, you shouldn't let them discourage you.

And to make you get all skeptical about working with classes and class declarations in JavaScript, as compared to the old, familiar non-class system:

JavaScript classes still make creating object-oriented code far more enjoyable: you get to code less, you get to write cleaner code...