- “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?
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.
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:
- also, there are no private members
Besides that, they do serve the same practical purpose and behave like any other class-based system.
Strict mode issues will inevitably lead to errors in your app.
- because the strict mode “challenges” classes to throw some of the once silent errors
“When do errors occur, more precisely?”
Mistake No. 2: Not Handling Subclasses Properly
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.
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”:
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.
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”.