Classes in ES6 section of the js course regarding "hoisting"

Question

The usage is vague and I was hoping someone explain it more in depth (not link to something.) Thanks!

Answer 1

Phil Andy Graves Thanks for rewording your question. I just went to that lesson to check and I see what you mean now.

It doesn't really explain it in any depth:

"Class Declarations are not hoisted while Function Declarations are. If you try to access your class before declaring it, ReferenceError will be returned."

That first sentence is a matter of debate. It's easier to think of classes as not hoisted because of how they behave: because they're not hoisted AND initialised, meaning you can't access them before their definition, they behave as though they're not hoisted. This does lead a lot of people to say they're not hoisted.

I'm not too bothered about these semantics. I do feel as though the way that let, const and classes behave is safer and less prone to bugs than the way that function and var behave.

Answer 2

https://code.sololearn.com/cRM5QUQSE14H/?ref=app

Answer 3

You're using many words there but let me try to piece together your question.

Maybe you are familiar with hoisting. If not:

const x = 3;
(() => {
console.log(x);
})();

This will print 3, obviously. the `x` in the function is taken from the enclosing scope.

const x = 3;
(() => {
console.log(x); // ReferenceError
const x = 4;
})();

This does not print 3. Rather it throws an error, even though we declared another x *after* it's used. Something fishy happened to your code: js hoisted the variable declaration and turned your code into (kinda)

const x = 3;
(() => {
const x;
console.log(x);
x = 4;
})();

The new x inside the function does not have a value yet so it throws a ReferenceError on use.

Classes are no different, they are a declaration, not unlike const.

class X{}
(() => {
console.log(X);
class X{}
})();

will also throw.

I'm not sure what you mean with modules. I hope that helped regardless. Hoisting exists for historical reasons, not because it's a good thing.

Answer 4

Class declararions are hoisted, there's no doubt about that, but their definitions aren't. I think the lesson just got it wrong honestly.

Try to predict what this code will do:

let x;
(() => {
x = 4;
class x {}
console.log(x);
})();

But I agree that ES6 makes hoisting a pretty unimportant detail. The guys are doing a good job of trying to mask this age old design flaw.

Answer 5

It's a bit difficult to know if this is what you're looking for without more detail about what you want, but here goes.

ES6 introduced let, const and classes (amongst others). Technically, these are hoisted but effectively in real usage, they behave as though they're not hoisted. That's because they're not initialised until they get evaluated. That's why you'll get a reference error if you try to use them above their definitions.

You can still reference these before the point at which they get evaluated as long as that code isn't executed. E.g. define a function which uses a class before the class itself is declared, but making sure to only call the function after the class declaration.

When it comes to classes in particular, one reason for why they don't have "normal" (pre-ES6 type) hoisting is because they can subclass using the extends keyword. By using extends, it means what you're extending gets evaluated so it needs to have been defined above.

Answer 6

Schindlabua I totally overlooked module. I meant a module as in a section of the course, not an javascript object module or other ecmascript shenanigans. I'll reword it!

Answer 7

CamelBeatsSnake Wow it goes beyond initializing. Thank you! I was speculating, and now I want to create some examples. Imagine dropping these in to see how it performs compared to functions and getting that reference error.

I bet that saves on memory though.