So Some basic examples of arrow functions might look like this.
If I am writing pure functions rather than any function that will be part of a prototype object that arrow functions will work just fine. However the value of the this keyword differs inside the body of an arrow function, so lets look at some more examples so we know when to use arrow functions and when to make use of one of the other options such as a function declaration.
Arrow functions are now yet another option on top of function expressions, and function declarations. I will not be getting into detail about expressions and declarations here. However I will say that arrow functions are not a replacement to these, they are just yet another option to work with.
The main difference between the two other options has to do with how the this keyword is handled in the body of an arrow function. With function expressions and declarations it is possible to set the value of the this keyword with Function.call, Function.apply, or Function.bind. However with arrow functions this does not work. An arrow function is also not a good choice when writing prototype methods for a class, again because of the nature of the this keyword when using arrow functions.
So with arrow functions the this keyword is not treated the same way as it is in other types of functions. When working with nested functions or closures the self variable is often used as a way to store the value of the this keyword that can then be accessed from within another nested function. In addition a Function prototype method like Function.call can be used to set the value of the this keyword as well when calling a function.
However with arrow functions the this keyword will not give expected results.
With arrow functions any value that is given for this via Function.call will just be ignored, and it will be as if the function was just called normally. There are some how say that this should not be used, as well as everything that this leads to. With that said if I where to stick to just working with values that are given via arguments then this should not be a problem. However there are problems with the arguments object also when it comes to arrow functions.
Another draw back of using arrow function is that the arguments object in the body of the function will not work as expected. The length property will give a value of zero when the actual number of arguments given is more than that. This is yet another reason why I often go with function expressions, or declarations over arrow functions.
So arrow functions are a nice addition but they are not always a drop in replacement for all functions that might exist in some legacy code. However when it comes to writing new code in a very functional way then just using arrow functions alone might work out okay.
Still it might be a good idea to at least be aware of the older function declaration and expression options and why it is that the use of them is not necessarily out dated. If you want to just choose one type of function all the time, then arrow functions might lead to problems when it comes to taking an approach where one needs to do things with Function prototype methods, and the arguments object, so maybe function expressions are a decent first choice still if you are not always sure which to use.