Difference and usage of common function and arrow function in JavaScript

  • 2021-08-05 08:25:09
  • OfStack

Recently, I was asked a question:

Arrow function in javaScript (= > ) and the normal function (function)?

What I thought at that time was: this question is very simple ~ (flag), and then I made the wrong answer...

The this in the arrow function is independent of the context when it is called, but depends on the context when it is defined

This is not a very correct answer... although it is not completely wrong

this in Arrow Function

First of all, there is no error in my answer: the this in the arrow function is really context-free when it is called


function make () {
  return ()=>{
    console.log(this);
  }
}
const testFunc = make.call({ name:'foo' });
testFunc(); //=> { name:'foo' }
testFunc.call({ name:'bar' }); //=> { name:'foo' }

This example shows that after the arrow function is defined, this will not change, and this will not change no matter what way it is called;

But strictly speaking, this is not "depending on the context of definition", because the arrow function does not bind its own this at all. When calling this in the arrow function, it is simply looking up the scope chain and finding the nearest this for use;
From the effect point of view, this is not much different from my previous understanding, but their essence is completely different. The arrow function is not an ordinary function that adds the feature that this is not affected by the context when calling, but reduces many features;

The arrow function is actually a simpler function

In fact, it is not only this that is different from ordinary functions in arrow functions. There are no local variables that are automatically bound like this in arrow functions, including this, arguments, super (ES6), new. target (ES6)...

To borrow an example from someone else:


function foo() {
  setTimeout( () => {
   console.log("args:", arguments);
  },100);
}
foo( 2, 4, 6, 8 );
// args: [2, 4, 6, 8]

In ordinary functions, all kinds of local variables will be automatically bound, and arrow functions are all 10 points simply looking up along the scope chain...

The arrow function is such a simple and pure thing;

Therefore, I personally think that arrow function is more suitable for functional programming. Besides being shorter, it is more difficult to use arrow function to be affected by variables that are not displayed and declared, which leads to unexpected calculation results;

So can ordinary functions achieve the same effect as arrow function 1?

If it is as simple as my original 1 to consider fixing this this changeable guy... that is very simple, some commonly used methods, such as this:


function make () {
  var self = this;
  return function () {
    console.log(self);
  }
}

Or


function make () {
  return function () {
    console.log(this);
  }.bind(this);
}

However, the second method can only fix the variable this. As mentioned above, variables such as arguments in the arrow function are also found from the scope chain. In order to achieve similar effects, we only have one way to redefine a local variable, and babel also uses this way to process the arrow function.


function make () {
  return ()=>{
    console.log(this);
    console.log(arguments);
  }
}
//babel it...
function make() {
  var _this = this,
    _arguments = arguments;
  return function () {
    console.log(_this);
    console.log(_arguments);
  };
}

So... what if I want to use arguments in the arrow function?

... I think if you have this requirement, it may be more appropriate to use ordinary functions.

But it doesn't mean that you can't get all the parameters in an array-like form in an arrow function. We can use the expansion operator to receive the parameters, such as this:


const testFunc = (...args)=>{
  console.log(args) // Output parameters in array form 
}

Maybe there are scenarios that need to be written in this way, but I still think that arrow functions are more suitable for simple cases that accept fixed parameters and return a calculation result;


Related articles: