Școala Web

Ce este hoisting-ul? Întrebarea preferată la interviurile de JavaScript

Ce este hoisting-ul? Întrebarea preferată la interviurile de JavaScript

Ce este hoisting în JavaScript? Este întrebarea care apare foarte des la interviurile tehnice de angajare. Îi vom răspunde în acest tutorial.

Deși am cunoștințe de bază sau chiar avansate în câteva limbaje de programare, m-am hotărât în ultimii ani să mă concentrez pe JavaScript.

S-a întâmplat ca în ultimul an să particip la mai multe interviuri tehnice pentru angajare.
Întrebările în general mi s-au părut ofensiv de ușoare și uneori irelevante dacă îți faci treaba bine.

O astfel de întrebare, pusă la majoritatea interviurilor, este legată de „hoisting” în JavaScript.

Cu mulți ani în urmă, la facultate am lucrat cu limbajul C. Nu C++, nu C#, ci bunicul lor din 1972.
Acolo toate variabilele se declară la începutul funcției. Așa că evident nu poți folosi nicio variabilă înainte să o declari.

Limbajele mai „moderne” nu mai sunt atât de pretențioase și poți să declari variabila mai aproape de locul în care o folosești.
Asta crește pericolul de a folosi din greșeală o variabilă înainte să o declari.

În JavaScript, variabilele declarate cu var pot fi folosite absolut oriunde în funcția în care au fost declarate, inclusiv înainte să fie declarate.

Pentru nu-știu-ce motiv, codul următor e perfect valid:

x = 96;

console.log(x);
// Output: 96

var x

Dar doar pentru că e valid, nu înseamnă că e o practică bună.

Niciun programator care se respectă nu va face asta cel puțin în cazul variabilelor.

„Hoisting-ul” este ideea că definițiile variabilelor cu var în JS sunt mutate la începutul contextului (funcției)

Cam asta trebuie să zici la interviul de recrutare

În Node și ES6, mai există două moduri de a declara variabile, cu let și const.
Aici chiar nu poți să te bazezi pe hoisting.

Definițiile sunt tehnic „mutate” la începutul blocului în care apar, dar practic nu poți să folosești variabilele înainte să le declari pentru că se generează o eroare.
Probabil vei descoperi eroarea respectivă în timpul dezvoltării.


Pot, totuși, vedea un caz în care s-ar putea folosi hoisting: dacă nu ai un sistem de module (import / export / require / ș.a.), poate ai nevoie să pui logica principală la început și funcțiile spre sfârșitul fișierului sau funcției:

console.log( x() );
// Output: 69

function x() {
    return 68+1;
}

Hoisting-ul se aplică și în cazul funcțiilor, cu un schepsis: întreaga declarație a funcției este „mutată” la începutul contextului.

La un moment dat, credeam că declarația function x este o prescurtare la var x = function.
Evident, hoisting-ul arată că nu este așa.

Însă în zilele noastre, fie că lucrezi pe front-end cu JS, fie că lucrezi pe back-end cu Node, probabil folosești un sistem de module.
Pe front-end probabil ai ES6 sau mai nou, „tradus” de Webpack cu Babel, deci poți folosi import și export.
La rându-i, Node are require(), care e un sistem asemănător dar puțin mai vechi.

De cele mai multe ori poți muta funcțiile într-un fișier separat.
Dacă funcțiile depind cumva de contextul fișierului în care lucrezi, și nu poți să le muți în afară, probabil faci ceva greșit.


Din punctul meu de vedere, hoisting-ul pentru variabile nu mai e relevant pentru că în ES6 au apărut let și const, care înlocuiesc var.
Pentru funcții, hoisting-ul poate fi util în anumite situații, dar ar trebui evitat.

Cu mintea mai la rece, pot să înțeleg că interviurile tehnice încearcă să filtreze oamenii.
Nu toți programatorii au trecut prin chinurile C-ului înainte să ajungă la acel interviu.
Eu însumi mă băteam cu pumnii în piept că „știu JS” cu ani în urmă când probabil înțelegeam un sfert sau mai puțin din ce înțeleg acum.

Conceptul de „hoisting” e bine de știut, mai ales când moștenești cod mai vechi, dar nu cred că este un criteriu foarte bun de evaluare a experienței.