Open panzerdp opened 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) :)
Comment written by Dmitri Pavlutin on 06/07/2016 04:28:18
You're right, thanks!
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.
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 :).
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...
Comment written by Dmitri Pavlutin on 06/08/2016 05:10:36
Sounds interesting :).
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. :)
Comment written by Dmitri Pavlutin on 06/09/2016 06:51:54
Thank you Suresh :).
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))
Comment written by Dmitry Manannikov on 06/10/2016 05:10:13
This text more about not to use "this"
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.
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).
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.
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.
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!
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 :).
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
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`
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.
Comment written by Nikos on 12/16/2016 09:32:27
Does `this` get preserved in arrow functions in events?
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);
Comment written by Dmitri Pavlutin on 12/26/2016 16:57:29
console.log('That\'s great!');
Comment written by David Kagawa-Aguirre on 01/06/2017 18:14:54
Fantastic article.
Comment written by Dmitri Pavlutin on 01/06/2017 19:00:10
Thanks!
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
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-...
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.
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.
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.
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.
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...
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 :)
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
Comment written by George Willian Condomitti on 07/19/2017 02:14:11
Very good article! Thanks and congratulations for such a great discussion.
Comment written by Dmitri Pavlutin on 07/19/2017 04:13:34
Thank you George.
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?
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.
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?
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
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)
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*.
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}
Comment written by hui on 11/23/2018 09:29:51
so appreciate for your article,can i translate into Chinese for others?
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`
Comment written by Anirudh Aima on 02/05/2019 13:02:02
Thanks for the help... But i had figured this out
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;
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.
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.
Comment written by Joan on 08/21/2020 03:08:44
this
won't help outside of the function either.
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
.
Written on 05/31/2016 14:35:05
URL: https://dmitripavlutin.com/when-not-to-use-arrow-functions-in-javascript/