原文地址&＃xff1a;Why Do We Write super(props) ?
原文作者&＃xff1a;Dan Abramov
译者&＃xff1a;Washington Hua
我听说 Hooks 最近很火。讽刺的是&＃xff0c;我想以一些关于 class 组件的有趣故事来开始这个博客。怎样&＃xff01;&＃xff08;皮一下很开心&＃xff09;
这些小坑并不会影响你高效的使用 React&＃xff0c;但如果你愿意深入了解下背后的工作原理&＃xff0c;你会发现它们非常有意思。
这是第一个。
我这辈子写过的 super(props) 比我想象的要多得多
class Checkbox extends React.Component {constructor(props) {super(props);this.state &＃61; { isOn: true };}// ...
}
当然&＃xff0c;class fields proposal 允许我们跳过这个仪式。
class Checkbox extends React.Component {state &＃61; { isOn: true };// ...
}
这样的语法是在 2015 年 React 0.13 增加对纯 Class 的支持的时候加入 计划 的. 定义 constructor 和调用 super(props) 一直都只是 class fiels 出现之前的临时解决方案。
然而&＃xff0c;让我们只用 ES2015 的特性来回顾一下这个例子。
class Checkbox extends React.Component {constructor(props) {super(props);this.state &＃61; { isOn: true };}// ...
}
我们为什么要调用super&＃xff1f;能不能不调用它&＃xff1f;如果非要调用&＃xff0c;如果不传 props 会怎样&＃xff1f;还有其它参数吗&＃xff1f;让我们来看一下。
在 Javascript 中&＃xff0c;super 指代父类的构造函数。&＃xff08;在我们的案例中&＃xff0c;它指向 React.Component 这个实现&＃xff09;
重点在于&＃xff0c;在你调用父类构造函数之前&＃xff0c;你无法在构造函数中使用 this。Javascript 不会允许你这么做。
class Checkbox extends React.Component {constructor(props) {// 这时候还不能使用 &＃96;this&＃96;super(props);// ✅ 现在开始可以了this.state &＃61; { isOn: true };}// ...
}
Javascript 强制你在使用 this 前运行父类构造函数有一个很好的理由。考虑这样一个类结构&＃xff1a;
class Person {constructor(name) {this.name &＃61; name;}
}class PolitePerson extends Person {constructor(name) {this.greetColleagues(); // 这是不允许的&＃xff0c;下面会解释原因super(name);}greetColleagues() {alert(&＃39;Good morning folks!&＃39;);}
}
想象一下如果在调用 super 前使用 this 是被允许的。一个月之后。我们或许会改变 greetColleagues 把 person 的 name 加到消息中。
greetColleagues() {alert(&＃39;Good morning folks!&＃39;);alert(&＃39;My name is &＃39; &＃43; this.name &＃43; &＃39;, nice to meet you!&＃39;);
}
但我们忘了 this.greetColleagues() 是在 super() 有机会设置 this.name 之前被调用的。this.name 甚至还没被定义&＃xff01;如你所见&＃xff0c;像这样的代码理解起来会很困难。
为了避免这样的陷阱&＃xff0c;Javascript 强制规定&＃xff0c;如果你想在构造函数中只用this&＃xff0c;就必须先调用 super。让父类做它该做的事&＃xff01;这一限制也适用于定义成类的 React 组件。
constructor(props) {super(props);// ✅ 现在可以使用 &＃96;this&＃96; 了this.state &＃61; { isOn: true };
}
这给我们留下了另一个问题&＃xff1a;为什么要传 props&＃xff1f;
你或许觉得把 props 传进 super 是必要的&＃xff0c;这使得基类 React.Component 可以初始化 this.props&＃xff1a;
// React 内部
class Component {constructor(props) {this.props &＃61; props;// ...}
}
很接近了——事实上&＃xff0c;它就是这么做的。
然而&＃xff0c;即便在调用 super() 时没有传入 props 参数&＃xff0c;你依然能够在 render 和其它方法中访问 this.props。&＃xff08;你要是不相信我&＃xff0c;可以自己试一试&＃xff09;
这是什么原理&＃xff1f;其实 React 在调用你的构造函数之后&＃xff0c;马上又给实例设置了一遍 props&＃xff1a;
// React 内部
const instance &＃61; new YourComponent(props);
instance.props &＃61; props;
因此&＃xff0c;即便你忘了把 props 传入 super()&＃xff0c;React 依然会在事后设置它们。这是有理由的。
当 React 添加对 Class 的支持时&＃xff0c;它并不是只添加了对 ES6 的支持&＃xff0c;而是希望能够支持尽可能广泛的 class 抽象。由于不是很确定 ClojureScript、CoffeeScript、ES6、Fable、Scala.js、TypeScript 或其他解决方案谁更适合用来定义组件&＃xff0c;React 对于是否有必要调用 super() 刻意不表态。
那么这是否意味着你可以只写 super() 而不用 super(props)&＃xff1f;
或许并非如此&＃xff0c;因为这依然让人困扰。诚然&＃xff0c;React 会在你的构造函数运行之后设置 this.props。但在 super 调用一直到构造函数结束之前&＃xff0c;this.props 依然是未定义的。
// React 内部
class Component {constructor(props) {this.props &＃61; props;// ...}
}// 你的代码
class Button extends React.Component {constructor(props) {super(); // 我们忘了传入 propsconsole.log(props); // ✅ {}console.log(this.props); // undefined }// ...
}
如果这发生在某些从构造函数中调用的函数&＃xff0c;调试起来会更加麻烦。这也是为什么我推荐总是使用 super(props) 的写法&＃xff0c;即便这是非必要的&＃xff1a;
class Button extends React.Component {constructor(props) {super(props); // ✅ 我们传了 propsconsole.log(props); // ✅ {}console.log(this.props); // ✅ {}}// ...
}
这样的写法确保了 this.props即便在构造函数返回之前就被设置好了。
最后还有一点是 React 的长期用户或许会好奇的。
你或许已经注意到&＃xff0c;当你在 Class 中使用 Context API 时&＃xff08;无论是旧版的语法还是 React 16.6 中新增的现代化语法&＃xff09;&＃xff0c;context 是被作为构造函数的第二个参数传入的。
那么我们为什么不写 super(props, context) 呢&＃xff1f;当然我们可以这么做&＃xff0c;但 context 的使用频率没那么高&＃xff0c;所以这个陷阱影响还没那么大。
伴随着 class fields proposal 的发布&＃xff0c;这个问题也就不复存在了。即便不显式调用构造函数&＃xff0c;所有参数也会自动传入。这就允许像 state &＃61; {} 这样的表达式在必要时可以直接引用 this.props. 或 this.context。
在 Hooks 中&＃xff0c;我们甚至都没有 super 或 this。这个话题我们择日再说。
京公网安备 11010802041100号