{"id":9267,"date":"2022-10-23T18:48:00","date_gmt":"2022-10-23T17:48:00","guid":{"rendered":"https:\/\/stevepedwards.today\/DebianAdmin\/?p=9267"},"modified":"2022-10-23T21:09:44","modified_gmt":"2022-10-23T20:09:44","slug":"js-behind-the-scenes-hoisting-and-the-tdz-temporal-dead-zone","status":"publish","type":"post","link":"https:\/\/stevepedwards.today\/DebianAdmin\/js-behind-the-scenes-hoisting-and-the-tdz-temporal-dead-zone\/","title":{"rendered":"JS Behind The Scenes : Hoisting and the TDZ – Temporal Dead Zone"},"content":{"rendered":"
<\/div>\n

<\/path><\/svg><\/i> \"Loading\"<\/p>\n

<\/div>\n

Hoisting by the JS Engine makes some variables available for use before they are declared by the JS engine creating a \"variable environment object\" as the code is initially scanned before being run.<\/p>\n

It is best to experiment with the various variable type to understand which get hoisted and which don't, as behaviour varies markedly.<\/p>\n\n\n\n
<\/td>\nHOISTED?<\/span><\/td>\nInitial Value<\/span><\/td>\nscope<\/span><\/td>\n<\/tr>\n<\/thead>\n<\/table>\n

 <\/p>\n\n\n\n\n\n\n
Function declarations<\/span><\/td>\nYes<\/span><\/td>\nActual function<\/span><\/td>\nblock<\/span><\/td>\n<\/tr>\n
var<\/span><\/td>\nYes<\/span><\/td>\nundefined<\/td>\nfunction<\/span><\/td>\n<\/tr>\n
Let\/const<\/td>\nNot in practice, technically Yes<\/td>\nUninitialized,<\/span><\/p>\n

Temporal Dead Zone<\/span><\/td>\n

block<\/span><\/td>\n<\/tr>\n
Func expressions\/Arrows<\/span><\/td>\nDepends if var or let\/const used<\/span><\/td>\n<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\/\/ Temporal Dead Zone, Let and Const: Function Declarations (function blah = {} etc) are hoisted \r\nconst myName = 'Jonas'\r\n\r\n\/\/ var \"job\" is defined but inaccesible - and VS code does not highlight ${} as a var either\r\nif (myName === 'Jonas') {\r\n  \/\/ -------------TDZ for job var-----------\r\n  console.log(`${job}`);\r\n  const job = \"teacher\"\r\n  \/\/ Uncaught ReferenceError: Cannot access 'job' before initialization - because of unhoisted variable const - if lines are reversed (Alt ^ arrow) then it works. Initially it is treated as not existing\r\n\r\n  \/\/ const age = 2037 - 1989\r\n  \/\/ console.log(age);\r\n  \/\/ 48\r\n  \/\/--------------TDZ for job var-----------\r\n  \r\n  \/\/ \r\n  \/\/-------------x is in TDZ until initialised _________\r\n  \/\/ console.log(x)\r\n  \/\/ Uncaught ReferenceError: x is not defined yet - it is in TDZ as uninitialized from JS initial code scan, so it is expected to be defined at some future point\r\n \/\/-------------x is in TDZ until initialised _________\r\n\r\n\r\n<\/pre>\n
\n
\n
So what is and why a TDZ? It was created in the JS Engine so that variables would not be accessible before they are declared to prevent bugs, bad programming practises and catch errors. So the JS engine in the browser F12 console flags an error and prevents continuation of the running code until fixed.<\/p>\n
It also makes const variables constant! They cannot be re-assigned later, else flag an error, unlike \"let\", partly.<\/p>\n
\/\/ basic assignment behaviour:\r\nlet a = 1\r\na = 2\r\n\/\/ no prob so far...!\r\n\/\/ let a = 3<\/span>\r\n\/\/ Identifier 'a' has already been declared<\/span>\r\n\r\nconst b = 2\r\n\/\/ b = 3<\/span>\r\n\/\/ Uncaught TypeError: Assignment to constant variable.<\/span>\r\n\r\nvar c = 1\r\nc = 2\r\nvar c = 3\r\n\/\/ no probs at all!! var is a wildcard that allows re-assignment at any point so makes keeping track of a var difficult across all scopes, whether global, local, functional or block scopes. It should not be used, but will exist in older code.<\/pre>\n
 <\/p>\n
Hoisting was created to make certain programming requirements possible even if it causes some confusion, a by product of which was the neccesity for var also being hoisted (and now still allowed to be defined as \"undefined\" instead of uninitialised, if not declared - a bad idea)\u00a0 in older versions of JS, which is why var should not be used any more, but let or const instead. The original JS design never intended or foresaw JS being used as it is now as such a powerful manipulator of CSS and HTML, due to Internet requirements.<\/p>\n<\/div>\n
So, how are variables hoisted or not if called before declaration?<\/div>\n<\/div>\n
<\/div>\n
\n
\/\/ console.log(me); \/\/ hoisted ok but undefined yet\r\n\/\/ undefined<\/span>\r\n\/\/ console.log(job); \/\/ in TDZ here\r\n\/\/ Uncaught ReferenceError: Cannot access 'job' before initialization<\/span>\r\n\/\/ console.log(year); \/\/ in TDZ here\r\n\/\/ Uncaught ReferenceError: Cannot access 'year' before initialization<\/span>\r\n\r\n\/\/ The let and const issues can be fixed by reversing their Top To Bottom order of being called\r\n\r\n\/\/\u00a0var\u00a0me\u00a0=\u00a0\"Fred\"<\/span>\r\n\/\/\u00a0let\u00a0job\u00a0=\u00a0\"teacher\"<\/span>\r\n\/\/\u00a0const\u00a0year\u00a0=\u00a01992<\/span><\/pre>\n
So how does function<\/em> hoisting behave?<\/p>\n
\/\/ Hoisting functions - declaration, expression and arrow:\r\nconsole.log(addDecl(2,3));\r\n\/\/ 5\r\n\/\/ declaration hoisted ok<\/strong><\/span>\r\n\r\nfunction addDecl(a,b) {\r\n  return a + b \r\n}<\/span>\r\n\r\n\/\/ console.log(addExpr(2,3));\r\n\/\/ Uncaught ReferenceError: Cannot access 'addExpr' before initialization\r\n\r\nconst addExpr = function (a,b) {\r\n  return a +b \r\n}\r\nAs with the variables defined by const and let above before, const functions are in the TDZ until their Top To Bottom order has changed places <\/span>\r\nconsole.log(addArrow(2,3));\r\n\/\/ Uncaught ReferenceError: Cannot access 'addArrow' before initialization\r\n\r\nconst addArrow = (a,b) => a + b\r\n\r\nAs with the variables defined by const and let above before, const functions are in the TDZ until their Top To Bottom order has changed places<\/span><\/span>\r\n<\/span><\/pre>\n
\n
The situation with var is different for 2 reasons - first, the expression alone IS hoisted but undefined, as the variable examples above.<\/div>\n<\/div>\n
<\/div>\n
\n
\/\/ console.log(addExpr);\r\n\/\/ undefined\r\n\r\n\/\/ but if arguments are given:\r\n\/\/ console.log(addExpr(1,2));\r\n\/\/ Uncaught TypeError: addExpr is not a function. This is because it is like using; \r\n\/\/ console.log(undefined(1,2));\r\n\/\/ Uncaught TypeError: undefined is not a function\r\n\r\nvar addExpr = function (a, b) {\r\n  return a + b;\r\n};<\/span>\r\n\r\n\/\/ Obviously, the same applies to an Arrow func\r\nconsole.log(addArrow(1,2));\r\n\/\/ Uncaught ReferenceError: Cannot access 'addArrow' before initialization\r\nlet addArrow = (a, b) => a + b;<\/span><\/pre>\n
SUMMARY: ONLY function Declarations are hoisted<\/span> by the JS Engine so work, no matter where - above or below each other - in the code the variable or declaration is placed.<\/strong><\/p>\n<\/div>\n
\n
\/\/ One last aspect of var is that it creates it's variables or functions as actual window objects, which may not be desireable:<\/div>\n
var x \u00a0= 1<\/span><\/div>\n
console.log(x \u00a0=== window.x);<\/div>\n
\/\/ true<\/div>\n
\/\/ Window {window: Window, self: Window, document: document, name: '', location: Location, \u2026}<\/span><\/div>\n
\/\/ x: 1<\/span><\/div>\n<\/div>\n<\/div>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
<\/div>\n
<\/path><\/svg><\/i> \"Loading\"<\/p>\n
<\/div>\n
Hoisting by the JS Engine makes some variables available for use before they are declared by the JS engine creating a \"variable environment object\" as the code is initially scanned before being run. It is best to experiment with the various variable type to understand which get hoisted and which don't, as behaviour varies markedly. ...\u00a0 JS Behind The Scenes : Hoisting and the TDZ – Temporal Dead Zone<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-9267","post","type-post","status-publish","format-standard","hentry","category-post"],"a3_pvc":{"activated":true,"total_views":4,"today_views":0},"_links":{"self":[{"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/posts\/9267","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/comments?post=9267"}],"version-history":[{"count":17,"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/posts\/9267\/revisions"}],"predecessor-version":[{"id":9284,"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/posts\/9267\/revisions\/9284"}],"wp:attachment":[{"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/media?parent=9267"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/categories?post=9267"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/stevepedwards.today\/DebianAdmin\/wp-json\/wp\/v2\/tags?post=9267"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}