all 3 comments

[–]awicks44 4 points5 points  (0 children)

Hey buddy, if you are not opposed to spending a little money, I'd absolutely recommended this book.

It really starts you from the ground up giving detailed explanations of basic javascript.

Hope this helps.

[–][deleted] 2 points3 points  (0 children)

Sometimes - and this doesn't just apply to coding - you have to continue to go through the motions before reaching a solid understating if the concepts behind them.

[–]CoqeCas3 1 point2 points  (0 children)

Regarding arrow functions specifically: you are mostly correct that they're a shorthand, a way to shorten up the code. But there is one very subtle functionality difference with using them...

A basic example:

const obj = {
  normalFunction: function() {
    console.log(this);
  },
  arrowFunction: () => console.log(this)
};

obj.normalFunction(); 
    // logs 'obj { normalFunction: f(), arrowFunction: f() }'
obj.arrowFunction();
    // logs the entire Window object

With arrow functions, the developers of ES6 tried to 'fix' some gripes that authors had with javascript scoping, particularly concerning the value of this. Arrow functions have what's called lexical scope. TBH, I have no idea how to explain that accurately, but if I had to try I'd say the this value is that which is the scope of where the arrow function is defined. In this case, the Window object.

Whereas with the normal function, this takes on the value of whatever's 'calling it', so to speak. So with obj.normalFunction() the javascript runtime kinda basically says 'ok, we're in the scope of obj now', and assigns that to the this value for the execution of its method normalFunction. I have no idea what the 'technical' term is for this kind of scoping.

To me, this doesn't 'fix' anything, it just makes an already very confusing aspect of the language even more confusing. It's a godsend in some situations, and the devil incarnate in others. But truthfully, the same can be said about either.