panzerdp / dmitripavlutin.com-comments

7 stars 0 forks source link

/when-not-to-use-arrow-functions-in-javascript/ #9

Open panzerdp opened 4 years ago

panzerdp commented 4 years ago

Written on 05/31/2016 14:35:05

URL: https://dmitripavlutin.com/when-not-to-use-arrow-functions-in-javascript/

panzerdp commented 4 years ago

Comment written by Šime Vidas on 06/07/2016 04:24:20

“Executing this.window” should be “Executing this.array” (in section 1.a) :)

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 06/07/2016 04:28:18

You're right, thanks!

panzerdp commented 4 years ago

Comment written by disqus_sIrHy9rk2t on 06/08/2016 03:15:52

You had me all the way up until point #4. That function isn't hard to read because of the fat arrow, it's hard to read because of the way you used the ternary. Consequently, when you made it more "readable," you removed the ternary. You could of just gave the fat arrow a function body and achieved the same result. Readability isn't really a valid criticism against fat arrows. When used properly they will enhance the readability of the code by providing the ability to write terse inline functions.

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 06/08/2016 04:58:11

Hey, thanks for your opinion!
Of course the arrow function short syntax improves the code readability.
My criticism is against the shortest possible code, which may be difficult to read. And in a fat arrow case it can go deeper with shortening.
My idea is to show the shortest and the verbose versions. And see what version is easier to understand quickly.
3 points from 5 - so the article was useful for you. Not bad :).

panzerdp commented 4 years ago

Comment written by Milan Lempera on 06/08/2016 05:04:45

Nice summary!
I think next case should be using in jasmine and mocha tests. Because they use this for tests context. See http://jasmine.github.io/2....this_keyword or http://mochajs.org/#arrow-f...

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 06/08/2016 05:10:36

Sounds interesting :).

panzerdp commented 4 years ago

Comment written by Suresh Raj on 06/09/2016 06:41:54

Just recently i found out your blog. Your writing style is very clean and easy to follow. Another great article. thank you. :)

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 06/09/2016 06:51:54

Thank you Suresh :).

panzerdp commented 4 years ago

Comment written by Dan Dart on 06/09/2016 21:52:21

I use arrow functions for events by using the event returned:

button.addEventListener('click', ev => console.log(ev.currentTarget))

panzerdp commented 4 years ago

Comment written by Dmitry Manannikov on 06/10/2016 05:10:13

This text more about not to use "this"

panzerdp commented 4 years ago

Comment written by Omer Ganim on 06/11/2016 12:21:36

Great article!
I think that in the cases with constructors and prototype methods, it would be more concise to use the "class" syntax. I can't say I'm a huge fan of JS classes in general, but if you're using them, using the class keyword seems clearer, and it allows you to use method shorthand like you did in 1a.

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 06/11/2016 16:51:06

It seems reasonable to use classes syntax if your environment allows ES6.
Me too, I don't use often "class". But I find them quite useful in creating React components for example (ES6 + JSX).

panzerdp commented 4 years ago

Comment written by David Gilbertson on 06/12/2016 10:34:44

Great article, very nicely explained. I think I may have stumbled over 1a in the past and not known why.

panzerdp commented 4 years ago

Comment written by Ruy Adorno on 06/16/2016 01:18:35

I would also add "Debugging", unnamed functions can be a pain to debug, specially in long stack traces.

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 06/16/2016 08:49:15

Hey Ruy,
Sounds reasonable to avoid anonymous functions.
At the moment browsers can infer the function name from it's variable. At least something :).
I like this article (by Todd Motto) that presents more details on the problem.
Thanks!

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 06/16/2016 08:51:53

Thanks David. The best for 1a is to use short method declaration. It's concise and works correctly :).

panzerdp commented 4 years ago

Comment written by jdfwarrior on 06/16/2016 12:08:46

Because that is one of the major benefits of using arrow functions is that you don't lose context (doesn't overwrite the "this" variable). Using "this" isn't bad and it doesn't make sense to always try and sidestep it in favor of something else

panzerdp commented 4 years ago

Comment written by yifeikong on 08/15/2016 01:01:58

I think it's fine to use arrow functions in event listeners, just use `event.currentTarget` instead of `this`

panzerdp commented 4 years ago

Comment written by andyrwebman on 11/18/2016 13:14:36

Some good points here, but I'd like to go further by saying it's not just arrow functions, it's overuse of inline anonymous functions, and functions declared within functions within functions. It seems messy to me, failing to encourage code re-use.

The newer class syntax as described in the link below should hopefully help out with this - see under the heading "Prototype methods". Neither arrow syntax or the function keyword is used.

https://developer.mozilla.o...

panzerdp commented 4 years ago

Comment written by Nikos on 12/16/2016 09:32:27

Does `this` get preserved in arrow functions in events?

panzerdp commented 4 years ago

Comment written by Diego Timido on 12/26/2016 07:56:32

Very well done. This is going in my Bookmarks for reference!
rainsoft.blog.apply(myBookmarks);

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 12/26/2016 16:57:29

console.log('That\'s great!');

panzerdp commented 4 years ago

Comment written by David Kagawa-Aguirre on 01/06/2017 18:14:54

Fantastic article.

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 01/06/2017 19:00:10

Thanks!

panzerdp commented 4 years ago

Comment written by Oki Erie Rinaldi on 01/18/2017 09:11:08

I wasted hours of time to figure out what happen to "this"-es in my script :|
I think that's why we need to "read the manual" before doing things

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 01/18/2017 18:51:37

The following article may help you understand better `this`: https://rainsoft.io/gentle-...

panzerdp commented 4 years ago

Comment written by Rawnsley on 02/28/2017 11:11:26

"Not supported by Internet Explorer" is another reason not to use them, which is a shame because they rock.

panzerdp commented 4 years ago

Comment written by MiltonDValler on 03/13/2017 15:55:30

Agree about classes (however they're implemented under covers) brings JS into the modern world. There's so much religion around prog' languages. Users are passionate to death about x or y feature.

panzerdp commented 4 years ago

Comment written by Igor Berlenko on 05/05/2017 07:36:19

"When calling the method, this becomes the object that method belongs to."
THIS becomes the object that method called on, it isn't always the object that method belongs to.

panzerdp commented 4 years ago

Comment written by Igor Berlenko on 05/05/2017 07:48:25

But above message is only right in the case of using function expressions.
In the case of using arrow function THIS always determines by lexical context.

panzerdp commented 4 years ago

Comment written by ngryman on 05/19/2017 06:35:41

Good point on this, but overall that's a matter of taste. I find this the more readable and idiomatic personally:


let multiply = (a, b) => b === undefined
? b => a * b
: a * b;

It makes me think of Haskell guards which is a beauty: http://learnyouahaskell.com...

panzerdp commented 4 years ago

Comment written by ngryman on 07/10/2017 16:17:15

Yeah :) Well to be diff friendly this is more correct:


let multiply = (a, b) =>
b === undefined
? b => a * b
: a * b;

It kind of follow the Elm Style Guide: https://gist.github.com/las...

But sometimes I find that it makes the code too tall so I adapt to my own flavor :)

panzerdp commented 4 years ago

Comment written by Mark Owuya on 07/11/2017 17:02:37

I just started to get the hang of arrow functions.
Should they be used in Node and Express?
Are they slower than the old school function(req, res){} ?

app.get('/', (req, res) => {
// Is this ok?
})

Thanks

panzerdp commented 4 years ago

Comment written by George Willian Condomitti on 07/19/2017 02:14:11

Very good article! Thanks and congratulations for such a great discussion.

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 07/19/2017 04:13:34

Thank you George.

panzerdp commented 4 years ago

Comment written by Matthew Shaile on 08/12/2017 19:30:27

How do you reference them later when you want to remove the listener?

panzerdp commented 4 years ago

Comment written by Salvatore Tedde on 09/13/2017 08:30:36

As long as you don't need to reference "this", then it's ok.

panzerdp commented 4 years ago

Comment written by Rahul Rastogi on 11/10/2017 07:10:49

Is overriding using arrow function in sub-class is possible in ES-06?

panzerdp commented 4 years ago

Comment written by Jordano Moscoso on 03/06/2018 03:41:42

Great article, i fall in the first mistake when I started to use the arrow syntax. Thanks mate

panzerdp commented 4 years ago

Comment written by Che Fisher on 03/15/2018 06:23:45

Sheesh... do we really think that adding a condition inside of a function which changes the returned value to another function instead of an (expected) number is an example of clear coding?

It reads well (i.e. the let double = multiply(2))) but to the trained eye, one would immediately notice that in the next line we are using double as a function... but where are the parenthesis one would expect to see when we declare a JavaScript function (arrow, shorthand, or otherwise)?

To understand why double is indeed a function we have to look at the internals of the multiply function - which means we are breaking Demeter's Law, summarised on WikiPedia as "[...the notion] that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents)".

It's also not very modular and it certainly isn't simple: multiple return statements nested at different levels in a single scope, while sometimes necessary, is pretty confusing! So, again, while complex structures are sometimes necessary, for all other cases let's KISS!

I know you probably just wanted to make a quick example and I think this is overall an excellent article (bookmarked a few of yours already!), but I must say that last example, for me, doesn't demonstrate your point very well (which is to reintroduce curly braces to make the code more readable). It's more readable than the single line ternary operator version, but it's still pretty unclear either way!

/End rant (bows)

panzerdp commented 4 years ago

Comment written by Asha8754 on 09/03/2018 12:56:17

https://uploads.disquscdn.c... They say that 1 out of a group of 5 guys is gay.... I'm really hoping it's Jake, because he's *super cute*.

panzerdp commented 4 years ago

Comment written by Anirudh Aima on 10/03/2018 09:52:50

I didn't get this part where I consoled "this" inside callback function of setTimeout .
when I use arrow function it loged person object and when i use regular function it loged window.
I
let person =function(name){
this.name=name;
this.getName=function(){

window.setTimeout(()=>{
console.log(this);
},1000);
};
};

let person1 = new person('tom');
person1.getName();
//output: person {name: "tom", getName: function}

panzerdp commented 4 years ago

Comment written by hui on 11/23/2018 09:29:51

so appreciate for your article,can i translate into Chinese for others?

panzerdp commented 4 years ago

Comment written by Austin Pham on 02/05/2019 12:30:54

I guess because `this` in arrow function target the context that wraps it. in this case the class person.

if change to normal function, since you're using window.setTimeout(). The target now changed to `window` so `this` changed to `window`

panzerdp commented 4 years ago

Comment written by Anirudh Aima on 02/05/2019 13:02:02

Thanks for the help... But i had figured this out

panzerdp commented 4 years ago

Comment written by Pankaj Doharey on 10/31/2019 17:47:46

For me it reads quite well just by adding a bracket (b) to the expression,
const multiply = (a, b) => b === undefined ? (b) => a * b : a * b;

panzerdp commented 4 years ago

Comment written by Dmitri Pavlutin on 10/31/2019 18:19:27

I think still it is difficult to read. :)
Anyways, often it's a matter of taste.

panzerdp commented 4 years ago

Comment written by Joan on 08/21/2020 03:08:01

I also disagree with this article on 2. Callback functions with dynamic context.
Proof is that in TypeScript, this is marked in as a parameter (see https://www.valentinog.com/... )
this is misleading and we should always use the event parameter instead.

panzerdp commented 4 years ago

Comment written by Joan on 08/21/2020 03:08:44

this won't help outside of the function either.

panzerdp commented 4 years ago

Comment written by Joan on 08/21/2020 03:10:11

You don't need to use this, just use the ev parameter it's much better than this.