为什么我们要写 super(props) ？

转载自https://overreacted.io/zh-hans/why-do-we-write-super-props/

据说 Hooks 势头正盛，不过我还是想略带调侃地从 class 的有趣之处开始这篇博客。可还行？

这些梗对于使用 React 输出产品并不重要，但如果你想深入的了解它们的运作原理，它们会非常的有用。

首先，在这一生中，super(props) 出现在我代码里的次数比我知道的还要多：

class Checkbox extends React.Component {
  constructor(props) {
    super(props);
    this.state = { isOn: true };
  }
  // ...
}

当然了，我们可以通过 class fields proposal 来省略这个声明：

class Checkbox extends React.Component {
  state = { isOn: true };
  // ...
}

早在 2015 年 React 0.13 已经计划支持 。在当时，声明 constructor 和调用 super(props) 一直被视作暂时的解决方案，直到有合适的类字段声明形式。

但在此之前，我们先回到 ES2015 风格的代码：

class Checkbox extends React.Component {
  constructor(props) {
    super(props);
    this.state = { isOn: true };
  }
  // ...
}

为什么我们要调用 super，我们可以不这么做吗？那么在我们调用它时不传入 props，又会发生什么呢？会有其他的缺省参数吗？接来下我们就解开这一系列谜题。

在 JavaScript 中，super 指的是父类（即超类）的构造函数。（在我们的例子中，它指向了 React.Component 的实现。）

值得注意的是，在调用父类的构造函数之前，你是不能在 constructor 中使用 this 关键字的。JavaScript 不允许这个行为。

class Checkbox extends React.Component {
  constructor(props) {
    // 🔴  还不能使用 `this`
    super(props);
    // ✅  现在可以了
    this.state = { isOn: true };
  }
  // ...
}

JavaScript 有足够合理的动机来强制你在接触 this 之前执行父类构造函数。考虑考虑一些类层次结构的东西：

class Person {
  constructor(name) {
    this.name = name;
  }
}

class PolitePerson extends Person {
  constructor(name) {
    this.greetColleagues(); // 🔴  这是禁止的，往后见原因
    super(name);
  }
  greetColleagues() {
    alert('Good morning folks!');
  }
}

试想一下，在调用 super 之前使用 this 不被禁止的情况下，一个月后，我们可能在 greetColleagues 打印的消息中使用了 person 的 name 属性：

greetColleagues() {
  alert('Good morning folks!');
  alert('My name is ' + this.name + ', nice to meet you!');
}

但是我们并未想起 this.greetColleagues 在 super() 给 this.name 赋值前就已经执行。this.name 此时甚至尚未定义。可以看到，这样的代码难以往下推敲。

为了避免落入这个陷阱，JavaScript 强制你在使用 this 之前先行调用 super。让父类来完成这件事情！：

constructor(props) {
  super(props);
  // ✅ 能使用 `this` 了
  this.state = { isOn: true };
}

这里留下了另一个问题：为什么要传入 props ？

你或许会想到，为了让 React.Component 构造函数能够初始化 this.props，将 props 传入 super 是必须的：

// React 內部
class Component {
  constructor(props) {
    this.props = props;
    // ...
  }
}

这几乎就是真相了 — 确然，它是 这样做 的。

但有些扑朔迷离的是，即便你调用 super() 的时候没有传入 props，你依然能够在 render 函数或其他方法中访问到 this.props。（如果你质疑这个机制，尝试一下即可）

那么这是怎么做到的呢？事实证明，React 在调用构造函数后也立即将 props 赋值到了实例上：**

// React 内部
const instance = new YourComponent(props);
instance.props = props;

因此即便你忘记了将 props 传给 super()，React 也仍然会在之后将它定义到实例上。这么做是有原因的。

当 React 增加了对类的支持时，不仅仅是为了服务于 ES6。其目标是尽可能广泛地支持类抽象。当时我们 不清楚 ClojureScript，CoffeeScript，ES6，Fable，Scala.js，TypeScript 等解決方案是如何成功的实践组件定义的。因而 React 刻意地没有显式要求调用 super() —— 即便 ES6 自身就包含这个机制。

这意味着你能够用 super() 代替 super(props) 吗？

最好不要，毕竟这样写在逻辑上并不明确确然，React 会在构造函数执行完毕之后给 this.props 赋值。但如此为之会使得 this.props 在 super 调用一直到构造函数结束期间值为 undefined。

// React 內部
class Component {
  constructor(props) {
    this.props = props;
    // ...
  }
}
// 你的程式碼內部
class Button extends React.Component {
  constructor(props) {
    super(); // 😬 我们忘了传入 props
    console.log(props);      // ✅ {}
    console.log(this.props); // 😬 未定义
  }
  // ...
}

如果在构造函数中调用了其他的内部方法，那么一旦出错这会使得调试过程阻力更大。这就是我建议开发者一定执行 super(props) 的原因，即使理论上这并非必要：

class Button extends React.Component {
  constructor(props) {
    super(props); // ✅ 传入 props
    console.log(props);      // ✅ {}
    console.log(this.props); // ✅ {}
  }
  // ...
}

确保了 this.props 在构造函数执行完毕之前已被赋值。

最后，还有一点是 React 爱好者长期以来的好奇之处。

你会发现当你在类中使用 Context API （无论是旧版的 contextTypes 或是在 React 16.6 更新的新版 contextTypes）的时候，context 是作为第二个参数传入构造函数的。

那么为什么我们不能转而写成 super(props, context) 呢？我们当然可以，但 context 的使用频率较低，因而并没有掘这个坑。

class fields proposal 出台后，这些坑大部分都会自然地消失在没有显示的定义构造函数的情况下，以上的属性都会被自动地初始化。这使得像 state = {} 这类表达式能够在需要的情况下引用 this.props 和 this.context 的内容。

然而，有了 Hooks 以后，我们几乎就不需要 super 和 this 了。但那就是另一个下午的茶点了。