具有shouldComponentUpdate与无状态组件的组件。性能?

时间:2017-08-21 10:58:10

标签: performance reactjs

我知道无状态组件使用起来比较舒服(在特定情况下),但由于你不能使用shouldComponentUpdate,这是否意味着组件将为每个道具更改重新渲染?我的问题是,使用具有智能的shouldComponentUpdate的类组件比使用无状态组件更好(性能方面)。

就性能而言,无状态组件是否是更好的解决方案? 考虑这个愚蠢的例子:

const Hello =(props) =>(
       <div>
           <div> {props.hello}</div>
           <div>{props.bye}</div>
       </div>);

VS

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个道具,我们只想更改其中一个道具(如果是常见用例),那么使用无状态功能组件或类是否更好?成分

更新

在做了一些研究后,我同意明确的答案。尽管类组件(使用shouldComponentUpdate)的性能更好,但似乎简单组件的改进可以忽略不计。所以我的看法是:

  • 对于复杂组件,使用由PureComponent或Component扩展的类(取决于您是否要实现自己的shouldComponentUpdate)
  • 对于简单组件使用功能组件,即使它意味着重新运行
  • 尝试从最近的类基本组件中删除更新量,以使树尽可能静态(如果需要)

1 个答案:

答案 0 :(得分:1)

我认为你应该阅读Stateless functional components and 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。否则使用常规功能应该没问题。我不认为为shouldComponentUpdate之类的组件实施Hello会产生很大的影响,它可能不值得花时间实施。 您还应该考虑从PureComponent而不是Component延伸。