why-do-we-write-super-props
原文: Why Do We Write super(props)?
我听说hooks最近很热。具有讽刺意味的是，我想通过描述有关类组件的有趣事实来开始这个博客。那会怎么样！
这些陷阱对于有效地使用React并不重要。但是如果你想更深入地了解事情的运作方式，你可能会发现它们很有趣。
这是第一个。
我写过的super(props)比我知道的要多:
class Checkbox extends React.Component {
constructor(props) {
super(props);
this.state = { isOn: true };
}
// ...
}当然，类字段提案让我们跳过仪式:
class Checkbox extends React.Component {
state = { isOn: true };
// ...
}当React 0.13在2015年增加对普通类的支持时，计划使用这样的语法。定义构造函数和调用super(props)成为临时解决方案，直到类字段提供符合人体工程学的替代方案。
但是，让我们回到这个例子，只使用ES2015功能：
class Checkbox extends React.Component {
constructor(props) {
super(props);
this.state = { isOn: true };
}
// ...
}我们为什么调用super？我们可以不调用它吗？如果我们必须调用它，如果我们不传递props会发生什么？还有其他论点吗？让我们来看看。
在JavaScript中，super指的是父类构造函数。（在我们的示例中，它指向React.Component实现。）
重要的是，在调用父构造函数之前，不能在构造函数中使用this。 JavaScript不会让你：
class Checkbox extends React.Component {
constructor(props) {
// 🔴 Can’t use `this` yet
super(props);
// ✅ Now it’s okay though
this.state = { isOn: true };
}
// ...
}有一个很好的理由说明为什么JavaScript在你触摸它之前强制执行父构造函数。考虑一个类层次结构：
class Person {
constructor(name) {
this.name = name;
}
}
class PolitePerson extends Person {
constructor(name) {
this.greetColleagues(); // 🔴 This is disallowed, read below why
super(name);
}
greetColleagues() {
alert('Good morning folks!');
}
}想象一下，在允许调用super之前使用this。一个月后，我们可能会更改greetColleagues以在邮件中包含此人的姓名：
greetColleagues() {
alert('Good morning folks!');
alert('My name is ' + this.name + ', nice to meet you!');
}但是我们忘记了在super调用有机会设置this.name之前调用this.greetColleagues。所以this.name甚至还没有定义！如您所见，这样的代码很难想到。
为了避免这些陷阱，JavaScript强制要求如果你想在构造函数中使用它，你必须首先调用super。让父级做自己的事！此限制也适用于定义为类的React组件：
constructor(props) {
super(props);
// ✅ Okay to use `this` now
this.state = { isOn: true };
}这给我们留下了另一个问题：为什么要传递props？
你可能认为将props传递给super是必要的，以便基本的React.Component构造函数可以初始化this.props：
// Inside React
class Component {
constructor(props) {
this.props = props;
// ...
}
}这与事实并不遥远 - 事实上，这就是它的作用。
但不知何故，即使你没有使用props参数调用super，你仍然可以在render和其他方法中访问this.props。 （如果你不相信我，请亲自试试！）
这是如何运作的？事实证明，在调用构造函数后，React也会在实例上分配props：
// Inside 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和构造函数结束之间仍然是未定义的：
// Inside React
class Component {
constructor(props) {
this.props = props;
// ...
}
}
// Inside your code
class Button extends React.Component {
constructor(props) {
super(); // 😬 We forgot to pass props
console.log(props); // ✅ {}
console.log(this.props); // 😬 undefined
}
// ...
}如果在从构造函数调用的某个方法中发生这种情况，则调试可能更具挑战性。 这就是为什么我建议总是传递super(props)，即使它不是绝对必要的：
class Button extends React.Component {
constructor(props) {
super(props); // ✅ We passed props
console.log(props); // ✅ {}
console.log(this.props); // ✅ {}
}
// ...
}这样可以确保在构造函数退出之前设置this.props。
最后一点React用户可能会对此感到好奇。
您可能已经注意到，当您在类中使用Context API时（使用遗留的contextTypes或React 16.6中添加的现代contextType API），上下文将作为第二个参数传递给构造函数。
那么为什么我们不写super(props, context)呢？我们可以，但上下文的使用频率较低，所以这个陷阱并没有那么多。
随着类字段的提议，这整个陷阱大多数都会消失。如果没有显式构造函数，则会自动传递所有参数。这允许像state = {}这样的表达式包含对this.props或this.context的引用（如果需要）。
有了Hooks，我们甚至没有super或this。但那是另一天的话题。
Last updated