Arrow Functions

Arrow Functions

Arrow function was introduced in ES6 using a new syntax for declaring functions called the arrow syntax. This new syntax uses less verbose syntax.

Arrow function can easily identified by the arrow symbol ‘ => ’ from where it gets its name. As part the syntax and rules for writing arrow functions is that the parameters come before the arrow element and the main body of the function comes after.

Arrow functions are always anonymous, and you need to assign them to a variable, so you can refer to them.

Advantage

There are numerous advantages of using arrow functions over other function declaration methods:

-They are much less verbose
-Do not need to use parentheses for single parameters
-The body of the function does not need to be placed inside a block if it is only one line
-If the return statement is the only statement in the body of the function, the return keyword is not required
-They do not bind their own value of this to the function

Example:

const square = x => x*x;

In this example the ‘x’ did not need to be in parentheses because is only one parameter; multiple parameters needs to go inside parentheses.

Example with two parameters:

const add = (x,y) => x = y;

But if the function does not require any parameters you can use empty parameters before the arrow symbol:

const hello = ( ) => alert(‘Hello World!’);

In all these examples the function fits onto one line, so there is no need to put them inside a block. But for longer functions you will require to use curly brackets to define the body of the function and the return keywork at the end.

const tax = (salary) => {
const taxable = salary – 5000;
const lowerRate = 0.25 * taxable;
taxable = taxable -15000;
const higherRate = 0.4 * taxable;
return lowerRate + higherRate;
}

As you can see the benefit of using arrow functions is lost when using it in a longer function. Arrow functions are a better fit for short and anonymous functions.

Comments

[Roman Paprotsky]

Hi Banesa,
Minor bug detected 😊

[Josh Chernoff]

I was just reading medium.freecodecamp.org/constant-c... and I think it had some very good examples as to why he used named functions primary. I agreed with the post.

[JavaScript Joel]

That article is from 2016 when people were more afraid of arrow functions.

I never use function in my code unless I need to access this. Because I try to write all my code without this, it's incredibly rare I every need function.

[Josh Chernoff]

Fare the link maybe a little dated but, the compromise that it highlights is still very much valid. In that you are adding (all be it small) a barrier of readability because of the ambiguity be tween constants and functions. The sole point of that article was not about arrow functions but rather how that impacts the ability to read the code more effectively. Your point lacks empathy for the people whom may end up reading your code and rather puts the onus that its more important that its easier to write because of X. Further more the point made on the order of procedure is also still very valid in that I will have to wade through method definitions before I even get to see the procedure of the code making the readability even more obscure. It's the everything looks like a nail syndrome. Sure you are avoiding the need for 'this' but at what cost?

I'm not trying to say you are wrong, frankly if it's helping you who am I to say otherwise. That said you should at least acknowledge there is a cost to it, that may end up helping you to empathize with your users which I believe holds the most value and that is what I believe that link really did a good job of explaining. Maybe try giving it another read and you will see what I mean.

[JavaScript Joel]

you are adding (all be it small) a barrier of readability

Ahh see maybe it's because I actually disagree with this in the article. That is why I suggested the content was dated. Because people weren't used to arrow functions. But they are so common place now. They are easily read by most people. And I find.them to be more readable than function. So that suggests "readability" is subjective.

The readability is also trending towards arrows and away from functions... So over time more and more people will prefer arrows.

Examples like:

list.map(function(item) { return item * 2})

list.map(item => item * 2)

To me, the latter is much easier to read. But I know readability is subjective. So I don't think anyone can make blanket statements saying one is "better" than the other. Because it depends on the person.

I can however tell you that the readability is trending towards arrows and over more time function will before less preferred.

[Josh Chernoff]

In your example you are displaying a typical subroutine thus this does make sense but if you are making everything a subroutine than you are not conveying the boundaries of you application very well are you?

[JavaScript Joel]

People often use the readability argument to argue against arrow functions. Not able to see what is and is not a function. That is just a matter of organization.

Put constants in one place, put functions in another. You should do this with or without arrow functions.

const two = 2
const three = 3

const double = x => x * 2
const tripple = x => x * 3

I have no problems seeing what is and what is not a function.

In the case of currying... I find the function keyword to be much harder to read.

function add(x) {
  return function(y) {
    return x + y
  }
}

// vs

const add = x => y => x + y

[JavaScript Joel]

conveying the boundaries of you application

I'm not fully understanding this

[JavaScript Joel]

It would be nice to have seen some examples demonstrating how arrow functions affect this

[Josh Chernoff]

Pulling from
developer.mozilla.org/en-US/docs/W...

You will see

Arrow function expression has a shorter syntax than a function expression and does not have its own this, arguments, super, or new.target. These function expressions are best suited for non-method functions, and they cannot be used as constructors.

note the non-method functions

heres some interesting thoughts on that point.
esdiscuss.org/topic/terminology-no...

[Palash Bauri 👻]

Const hello = ( ) => alert(‘Hello World!’);

Const should be const

[Banesa Guaderrama]

Hey Palash - Thank you for the catch... I will edit it. Thanks for reading!!!

Banesa