/variables-lifecycle-and-why-let-is-not-hoisted/ about dmitripavlutin.com-comments HOT 18 OPEN

Comment written by Kostya on 07/27/2016 19:42:55

Дмитрий, спасибо большое за такие исчерпывающие и крутые статьи. Мне кажется, что изучали Вы JS не по книжкам, а сразу со спецификации начали :)

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 07/28/2016 07:34:45

Hi Kostya,
I do learn JavaScript from books, but the source of final truth of course is the specification :)
Enjoy the reading!

from dmitripavlutin.com-comments.

Comment written by Ruslan on 08/02/2016 09:01:21

Спасибо!
P.S.: очень крутые космические хедеры

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 08/02/2016 09:22:58

Thanks!

from dmitripavlutin.com-comments.

Comment written by J1 on 08/09/2016 10:37:44

Can I translate and share this post on my blog with source?

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 08/09/2016 11:10:12

Hey J1,
Sure you can translate! Just post a link back to the original :).
If you need any assistance, let me know.

from dmitripavlutin.com-comments.

Comment written by Tung Dang on 08/14/2016 06:32:45

I love the way you explain with illustrative pictures. Thank you.

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 08/14/2016 11:38:05

Thanks @tung Dang. Images indeed are helpful for an easier understanding.

from dmitripavlutin.com-comments.

Comment written by JSer on 08/24/2016 09:32:10

Hey, thanks for the article!

I have a question about "The variable num is accessed before declaration var num, so it is evaluated to undefined."

Isn't the reason num evaluates to undefined is that it is accessed before the assignment expression? (not declaration)

I.e.
var num; // declaration
num; // => undefined
num = 10; // assignment
num; // => 10

Thanks!

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 08/25/2016 05:19:34

Hey JSer, you're welcome!
Nope, the place in code where var num; appears does not matter: before it or after it the variable is undefined. It happens because the variable is initialized and has undefined value at the beginning of the function scope - which means hoisting.

from dmitripavlutin.com-comments.

Comment written by Anders Ringqvist on 09/07/2016 12:33:33

Really nice explanation, specially with the graphics. Variable declarations with var being hoisted can really throw off even the most seasoned JS dev. I guess that's the reason most devs configure their linters to throw at undeclared vars. I have however started to observe a new wtf moment among some devs and that is the _tdz_ that you mention. It's however easer to explain than var hoisting. Now to my thoughts on "best practice" =P

Function declaration hoisting is a killer feature in JS. It lets you keep the exposed API and interesting shallow init implementation of a module in the beginning of a file and lets you bury specific implementation details below. Taking advantage of function declaration hoisting will make the code easier to scan for new team members and if needed gives opportunity to "drill down into implementation details".

Coming to a new code base I'm usually first interested in API, contracts between modules and function signatures. Being forced to scroll passed 100 function declarations or use shortcut key combo to scroll to bottom and then scrolling up random number of lines before arriving at export, module.exports or the init() in every module is a waste of time.

As time goes by and I am becoming accustomed to the code base I usually want to "drill down" from the API into specific implementation to fix bugs or add stuff. Opening a file and staring at a

export {/*revealing api*/};

or

module.exports = {/*revealing api*/};

is a bliss and makes work so much easier.

As your example with sumArray() shows. At first I would only be interested in what it actually does with it's input e.g. reduce. Usually I'm fine here and can go on with by business, but if I want to know more I can easy drill down into sum() by "go to definition". Now imagine that the implementation of sumArray was at the bottom (or close to the bottom) of the function body and that it was not only one reduce but a few map and filter as well. Being forced to scroll passed a bunch of functions that at the time of reading them actually doesn't mean anything to the reader. That is unnecessary cognitive load.

As wise old Obi-Wan said: Use the (function declaration) hoisting Luke…

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 09/08/2016 11:03:17

Hello @andersringqvist:disqus,
Thank you for the detailed review.
The best option in my opinion is to declare, initialize and then use. This simple approach is always correct.
With the exception as you mention of the function declaration hoisting. It allows to create more organized function structures. Function invocation happens at the beginning of the file, and the declaration is at the end (which is possible due hoisting). So you don't have to scroll through function implementation details if you don't need to.
Thanks!

from dmitripavlutin.com-comments.

Comment written by Ivan Kleshnin on 11/16/2016 20:35:17

Great article. Thanks for making it.

Unfortunately, I think the "let does not hoist" is not entirely correct. See http://jsrocks.org/2015/01/... If hoisting was not in case, the usage of `x` before `let x` inside of a function with a global `x` in scope would refer to the global version. But this does not happen (exception happens instead). The presence of `let x` declaration overrides "global" `x` in the whole block (function in this case)!

```js
let x = "global"
function f() {
console.log(x) // without hoisting it would be "global"
let x = "local"
console.log(x)
}

f()
```

Hoisting does not mean the collapsing of phases. Instead, it means that interpreter knows and tracks which variables will be used down the code within the block (block meaning is different for `var` and `let`) – and does not look for them in outer scopes.

from dmitripavlutin.com-comments.

Comment written by praky on 12/02/2017 18:33:42

Much clearer and concise yet exhaustive than what is explained in the "You don't know JS" series. Excellent work Dmitri!

from dmitripavlutin.com-comments.

Comment written by Dmitri Pavlutin on 12/03/2017 08:15:32

Thanks! God is in the detail :).

from dmitripavlutin.com-comments.

Comment written by Codingstorytime on 02/22/2020 17:52:23

do you still believe this in 2020 that let is not hoisted

from dmitripavlutin.com-comments.

Comment written by dracyoda on 03/27/2020 15:25:42

Just saw getify's comments on this topic in your mentioned thread. But you did a fantastic job explaining these in much clearer way. Grateful.

from dmitripavlutin.com-comments.

Hello sir..... Question on ... let variable lifecycle ... Reference Error: can't access variable before initiazation......... Should be ..... Is am right???
Your article is following below..
Now let’s study a scenario when the interpreter enters a block scope that contains a let variable statement. Immediately the variable passes the declaration phase, registering its name in the scope (step 1).
Then interpreter continues parsing the block statements line by line.

If you try to access variable at this stage, JavaScript will throw ReferenceError: variable is not defined. It happens because the variable state is uninitialized.
variable is in the temporal dead zone.

from dmitripavlutin.com-comments.