原文: Why Do We Write super(props)?
本文原文: 为什么写render(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
。但那是另一天的话题。
网友评论