-1

So with ES6 we have arrow-functions which - next to maintaining the this context - increase readability in my opinion.

Common Samples: [...].map(item => item.attr) or [...].reduce((a,b) => {...} ).

So I am asking myself: Is it considered good practice to use these arrow functions instead of function(){...}. Because that is what you see nowadays.

My personal 2 cents on this:

  • Seen from a view of readability and maintainability I'd like to generally use arrow functions
  • Seen from a technical and contextual view I consider using arrow functions should be an exception and not the norm as it can lead to unwanted behaviour. E.g.: Changing the context of an arrow functions is senseless: (()=>{}).apply(window) will have absolutely no effect. That said: A library that needs a specific context could be easily brought to its knees by arrow functions.

This is just a small extract of my thoughts. I have this certain paranoia everytime I am using arrow functions as I feel it is a wrong thing to do when you do not actually need to remain in that context.

androidavid
  • 1,088
  • 1
  • 7
  • 17

3 Answers3

0

Arrow functions, as you've said, lexically binds this. It also provides some syntactic sugar. That makes it great in a few circumstances, like using in a method call that takes a function as an argument (.map(), .filter(), etc.)

As far as standards go, there are none. There are certainly places where you do not want to use an arrow function, like when defining a method, but in most cases you will just want to go with whatever your team is using - you may think it looks more semantic and readable, but your team may not.

For front-end web development, arrow functions aren't as common as you'd think, unless you're maintaining Babel on top of it. For Node development, I'd like to see more arrows, but for the most part they are a niche item and in most cases don't really provide any objective benefit from just using function().

joh04667
  • 6,035
  • 18
  • 30
-1

From what I understand, there is little performance difference when using a transpiler, since it parses it into ES5, so even if you don't need the context binding, it doesn't hurt to be consistent.

Natively, I've heard there is a slight performance hit in some browsers, but when ES6/7 is fully implemented and optimized in browsers, that may go away.

Considering the advantages in terseness and clarity, I don't think there would be a reason not to use them once it's fully supported.

SchattenJager
  • 293
  • 2
  • 14
-1

It is a good practice to be aware of what is the context for current arrow function.

Arrows can't be constructors.

Non-lexical this is something that was abused often before and is something that is rarely a good idea in ES6 development. If the one is writing ES6 code for jQuery, a string should probably be tied on his/her finger if this is a problem.

Estus Flask
  • 150,909
  • 47
  • 291
  • 441
  • Looks like some nice SO expert just exploded with negative over this question. Keep up the good work, never keep it to yourself. – Estus Flask Sep 19 '16 at 21:03