Understanding arrow functions

I used to feel that I already understood arrow functions very well, and it was impossible to be fooled again. But I encountered a very strange problem a few days ago. After worrying about it for a long time, I found that it was a pitfall caused by the arrow function. Therefore, there is this article~

Problem Description

For example, I have a base class Animal, which has a basic method sayName. Each subsequent subclass that inherits from it needs to implement the sayName method to prove its identity. The base class code implementation is very simple:

class Animal {
	sayName = () => {
		throw new Error('你应该自己实现这个方法');
  }
}

So now I have to inherit from the Animal base class to implement a Pig subclass. The implementation is also very simple:

class Pig extends Animal {
	sayName() {
		console.log('I am a Pig');
	}
}

Hey, is it so simple? ? Where is the pitfall? However, when you actually run it, you will find that the result is not as expected:

Hey, why is this happening? What exactly went wrong? Why can this short few lines of code report an error?

Discover the problem

After a lot of tossing, I finally found that it was a pitfall of the arrow function. We only need to change the sayName of the Animal base class to a normal function, or change the sayName of the Pig subclass to an arrow function to solve this problem. So, what exactly is going on with arrow functions?

Writing this, I suddenly remembered that I was once interviewed by an interviewer about this question! At that time, the interviewer asked about the difference between arrow functions, ordinary functions of the class, and bind functions in the constructor for classes. The answer was clear and logical at the time, but when it came to inheritance, everything turned upside down. So to answer the above question, let’s first answer the interview question.

What is the difference between arrow functions, ordinary functions, and the bind function in constructor?

In order to see this problem more intuitively, we can use babel’s code compilation results to Better to see the difference.

First we enter a simple piece of code

class A {
  	constructor() {
		this.b = this.b.bind(this);    	
    }
  
    a() {
    	console.log('a');
    }
	  b() {
    	console.log('b')
    }
    c = () => {
    	console.log('c')
    }
}

Let’s see what babel compiles into:

"use strict";

function _instanceof(left, right) { if (right != null && typeof Symbol !== "undefined" && right[Symbol.hasInstance]) { return !!right[Symbol.hasInstance](left); } else { return left instanceof right; } }

function _classCallCheck(instance, Constructor) { if (!_instanceof(instance, Constructor)) { throw new TypeError("Cannot call a class as a function"); } }

function _defineProperties(target, props) { for (var i = 0; i < props.length; i++) { var descriptor = props[i]; descriptor.enumerable = descriptor.enumerable || false; descriptor.configurable = true; if ("value" in descriptor) descriptor.writable = true; Object.defineProperty(target, descriptor.key, descriptor); } }

function _createClass(Constructor, protoProps, staticProps) { if (protoProps) _defineProperties(Constructor.prototype, protoProps); if (staticProps) _defineProperties(Constructor, staticProps); return Constructor; }

function _defineProperty(obj, key, value) { if (key in obj) { Object.defineProperty(obj, key, { value: value, enumerable: true, configurable: true, writable: true }); } else { obj[key] = value; } return obj; }

var A = /*#__PURE__*/function () {
  function A() {
    _classCallCheck(this, A);

    _defineProperty(this, "c", function () {
      console.log(&#39;c&#39;);
    });

    this.b = this.b.bind(this);
  }

  _createClass(A, [{
    key: "a",
    value: function a() {
      console.log(&#39;a&#39;);
    }
  }, {
    key: "b",
    value: function b() {
      console.log(&#39;b&#39;);
    }
  }]);

  return A;
}();

Most of the compiled code is auxiliary functions , we can only look at part of the key points:

var A = /*#__PURE__*/function () {
  function A() {
    _classCallCheck(this, A);

    _defineProperty(this, "c", function () {
      console.log('c');
    });

    this.b = this.b.bind(this);
  }

  _createClass(A, [{
    key: "a",
    value: function a() {
      console.log('a');
    }
  }, {
    key: "b",
    value: function b() {
      console.log('b');
    }
  }]);

  return A;
}();

From the compiled results, we can see the differences between each other:

• Ordinary functions: After babel compilation, Will be placed on the prototype of the function

• The bind function in the constructor: After compilation, it will not only be placed in the prototype of the function, but also will be generated every time it is instantiated. Bind the variable of the current instance context (this.b = this.b.bind(this)).

• Arrow function: After babel is compiled, each time it is instantiated, defineProperty will be called to bind the arrow function content to the current instance context.

Judging from the compiled results, for actual development, if you need to bind context, it is best to use arrow functions. Because using the bind method will not only generate a prototype function, but also generate an additional function for each instantiation.

Update

After reading Yu Tengjing’s comments, I learned something more essential.

class For methods and variables declared with = sign, they will be used as attributes of the instance, while for attributes declared without = sign, they will be placed on the prototype chain. For example,

class A {
    a() {
        
    }
    b = 2;
    c = () => {
    }
}

For this class, when instantiated, b and c will be used as attributes of the instance, while a is placed on the prototype chain.

So why is it implemented like this? In fact, we can see that this is mentioned in the tc39 specification: Field declarations

For instances where the equal sign declaration is written directly, it is actually the syntax of Field declarations, which is equivalent to directly declaring such an instance attribute.

Back to topic

After we solve the previous problem, let’s return to the topic. After understanding the compilation results of the arrow function of the class in actual compilation conditions, it is actually easier to understand our problem.

Q: Why does an execution problem occur when a subclass declares sayName using a normal function?

A: If a subclass declares sayName using a normal function, the sayName declared by the subclass will be placed on the prototype of the constructor. However, since the base class's sayName uses arrow functions, each instance will directly have a sayName variable. According to the access rules of JavaScript variables, the variable itself will be searched first, and if it cannot be found, it will be searched on the prototype chain. Therefore, when looking for sayName, we directly find the sayName function declared by the base class, and will not look for it on the prototype chain, so there is a problem.

Q: Why does the subclass use arrow function to declare sayName and there is no problem in execution?

A: When an es6 class is initialized, it will first execute the constructor of the base class, and then execute its own constructor. Therefore, after the base class is initialized, the arrow function sayName declared by the subclass overrides the base class's, so there is no problem in execution.

Summarize

I thought I knew arrow functions very well, but I was fooled. Sure enough, there is no end to learning! But I also have a deeper understanding of intra-class arrow functions.

But after being reminded by everyone in the comment area, I found that the problem is not actually caused by the arrow function. Variables declared with the = sign in the class belong to the syntax of Field declarations. For variables declared in this way, they will be directly mounted to the properties of the instance instead of being mounted to the prototype chain.

Recommended tutorial: "JS Tutorial"

The above is the detailed content of Understanding arrow functions. For more information, please follow other related articles on the PHP Chinese website!