...and only underscore _ is required when there is no argument
This is not correct. If you put an underscore there, your function is accepting an argument called _ - and you are just choosing to ignore it. The correct way to do it is:
constshootArrow=()=>console.log("shooting arrow")
This can also be verified by checking the length property of the function that returns the number of non-optional parameters it takes:
If you write functions that take no arguments in the way you describe - you could end up with issues when working with libraries that make use of .length. It is also not good for readability.
Problem #5/#6 is a good thing to me. People mess up this bindings way too often. I stopped using this ~2012, and stopped writing mutative code around the same time, and life has only gotten better, as whole classes of bugs disappeared. But if it helps:
class Example {
data = Math random();
doX = () => console log(this.data);
}
using the arrow like this will always get the binding right. Even if you pass the function in as a callback, or save it as a variable, or reference it on a different object, et cetera. Something that the other functions do not get right.
Issue #7 isn't because of the arrow function, it's because of the const keyword. A const can't have a competing name in the same context.
function test() {}
const test = 5; // <-- this explodes because "test" is already declared
The same thing happens when you use const to shadow the name of an argument.
const f = (x) => {
const x = 5; // <-- explodes for the same reason as above
};
Issue #8 actually has 2 bugs. The first is to do with const, not the function.
console.log(x); // <-- access before initialization
const x = 5;
This is the deadzone. You can't use a let or a const above where it is declared. Even if there is something with the same name in an outer scope.
const x = 5;
const f = () => {
console.log("outer x");
console.log(x); // <-- this errors; can't use both xs in the same scope with let/const. It's treated as inner-x and is used in the deadzone
// inner x
const x = 6;
};
The second problem with #8 is specific to functions, but not unique to arrows.
Function hoisting does not work on any function expression of any kind, including assignment statements. Even if you are using var.
function hoisted () {}
var f1 = function nope () {};
nope(function not_me_either () {});
window.addEventListener("load", function not_a_chance() {});
The only functions that are hoisted are function declarations.
For that reason and others, it's better to not run the code in the same file that you define the code.
So are function expressions. Even if you name a function expression it is still not hoisted.
There are many ways of defining functions and there is exactly 1 of those ways that is hoisted.
// function declaration
// hoisted
function a () {}
// function expression: named
// not-hoisted
const b = function B () {}; // name only exists inside B (ie: recursion)
// function expression: anonymous
// not-hoisted
const c = function () {};
// lambda expression
// not-hoisted
const d = () => {};
So your problem is with literally all function expressions, which... fine... prefer declarations if you want to. But for people who prefer expressions, there is no difference between using the arrow and not, for #8, so using arrows is just more concise.
Yes, function expressions are optional. Function declarations are optional, too. Only function declarations can be hoisted, so if you choose to use any form of expression, your functions aren't hoisted, regardless of whether they are named, unnamed, arrow, or otherwise.
Re: #7 let and const have the same rules regarding deadzones and variable shadowing. Try it again with var.
Or just try
function x () {}
let x = 5;
There's no arrow function there, so why is the error the same?
This is not correct. If you put an underscore there, your function is accepting an argument called
_- and you are just choosing to ignore it. The correct way to do it is:This can also be verified by checking the
lengthproperty of the function that returns the number of non-optional parameters it takes:If you write functions that take no arguments in the way you describe - you could end up with issues when working with libraries that make use of
.length. It is also not good for readability.Thanks for the feedback i have adjusted that portion to better convey my thoughts
I also adjusted my comment to better convey my thoughts 😀
lol .. just followed you
Problem #5/#6 is a good thing to me. People mess up
thisbindings way too often. I stopped usingthis~2012, and stopped writing mutative code around the same time, and life has only gotten better, as whole classes of bugs disappeared. But if it helps:using the arrow like this will always get the binding right. Even if you pass the function in as a callback, or save it as a variable, or reference it on a different object, et cetera. Something that the other functions do not get right.
Issue #7 isn't because of the arrow function, it's because of the const keyword. A const can't have a competing name in the same context.
The same thing happens when you use const to shadow the name of an argument.
Issue #8 actually has 2 bugs. The first is to do with const, not the function.
This is the deadzone. You can't use a let or a const above where it is declared. Even if there is something with the same name in an outer scope.
The second problem with #8 is specific to functions, but not unique to arrows.
Function hoisting does not work on any function expression of any kind, including assignment statements. Even if you are using var.
The only functions that are hoisted are function declarations.
For that reason and others, it's better to not run the code in the same file that you define the code.
but arrow function are always written as expression otherwise they are anonymous so...
So are function expressions. Even if you name a function expression it is still not hoisted.
There are many ways of defining functions and there is exactly 1 of those ways that is hoisted.
So your problem is with literally all function expressions, which... fine... prefer declarations if you want to. But for people who prefer expressions, there is no difference between using the arrow and not, for #8, so using arrows is just more concise.
Yes i gave an example of that in the beginning; you can write normal function as an expression but its optional.
also no # 7 is not because of the const keyword (try let keyword with my example to confirm)
I Appreciate #6 comment
Yes, function expressions are optional. Function declarations are optional, too. Only function declarations can be hoisted, so if you choose to use any form of expression, your functions aren't hoisted, regardless of whether they are named, unnamed, arrow, or otherwise.
Re: #7
letandconsthave the same rules regarding deadzones and variable shadowing. Try it again withvar.Or just try
There's no arrow function there, so why is the error the same?
#7 was about parameters not declaration or identifiers
Really got my knowledge of arrow function, declaration and the "this" key refreshed once again. This is resourceful