我知道无状态组件使用起来要舒服得多(在特定情况下(，但是由于您不能使用 shouldComponentUpdate，这是否意味着组件将为每个 props 更改重新渲染？我的问题是，使用具有智能 shouldComponentUpdate 的类组件是否比使用无状态组件更好(性能方面(。
就性能而言，无状态组件是更好的解决方案吗？ 考虑这个愚蠢的例子：
const Hello =(props) =>(
<div>
<div> {props.hello}</div>
<div>{props.bye}</div>
</div>);
与
class Hello extends Component{
shouldComponentUpdate(nextProps){
return nextProps.hello !== this.props.hello
};
render() {
const {hello, bye} = this.props;
return (
<div>
<div> {hello}</div>
<div>{bye}</div>
</div>
);
}
}
假设这些组件都有 2 个 prop，并且如果更改(这是一个常见的用例(，我们只想跟踪和更新其中一个，使用无状态功能组件还是类组件更好？
更新
在做了一些研究之后，我也同意标记的答案。尽管在类组件(使用 shouldComponentUpdate(中性能更好，但对于简单组件来说，改进似乎可以忽略不计。所以我的看法是这样的：
- 对于复杂的组件，请使用PureComponent或Component扩展的类(取决于你是否要实现自己的shouldComponentUpdate(
- 对于简单组件 使用功能组件，即使这意味着重新渲染运行
- 尝试从最接近的类基组件中减少更新量，以使树尽可能静态(如果需要(
我认为您应该阅读无状态功能组件并应该组件更新#5677
对于复杂的组件，定义 shouldComponentUpdate(例如纯渲染(通常会超过无状态组件的性能优势。文档中的句子暗示了我们计划的一些未来优化，我们不会为无状态功能组件分配内部实例(我们只调用函数(。我们也可能不会继续持有道具等。 微小的优化。我们不会在文档中讨论细节，因为优化尚未实际实现(无状态组件为这些优化打开了大门(。
https://github.com/facebook/react/issues/5677#issuecomment-165125151
目前没有对函数进行特殊优化，尽管我们将来可能会添加此类优化。但就目前而言，它们的表现与类完全一样。
https://github.com/facebook/react/issues/5677#issuecomment-241190513
我还建议检查 https://medium.com/missive-app/45-faster-react-functional-components-now-3509a668e69f
为了衡量变化，我创建了这个基准，结果相当惊人！从仅仅将基于类的组件转换为功能组件，我们得到了 6% 的加速。但是通过将其调用为一个简单的函数而不是安装，我们得到了~45%的总速度改进。
回答这个问题：这取决于。 如果您有复杂/繁重的组件，您可能应该实现shouldComponentUpdate。否则，使用常规函数应该没问题。我不认为为像你这样的组件实现shouldComponentUpdateHello会产生很大的不同，它可能不值得花时间实现。 您还应该考虑从PureComponent而不是Component扩展。