• Reactjs 列表优化的一些心得


    前言

    在应用开发中,列表是我们使用频率非常高的一种展现形式,在reactjs项目中更是如此。无处不在的使用更是需要我们小心触发性能瓶颈的深水炸弹。

    下面就我最近的总结出的几点心得分享给大家,有什么问题欢迎批评指正。

    不要用索引当key

    reactjs要求我们对列表中的每一项设置一个唯一的key值,这个虚拟dom的diff算法有很大关系。简单的说,在同一级dom树中,有2种情况会引起元素(这里的元素指的是虚拟dom,而不是真正的dom元素)的增删。

    1.元素的类型改变
    2.key值变化

    在列表中,元素类型一般是相同的,所以我们需要根据唯一的key值来给当前元素加上标记,这样reactjs才能感知元素是否需要增加或删除了。

    reactjs采用的非常直接粗暴的算法来判断元素的增删,比如

    旧的

    
    <li key={1}>a</li>
    <li key={2}>b</li>
    

    新的

    
    <li key={1}>a</li>
    <li key={2}>b</li>
    <li key={3}>c</li>
    <li key={4}>d</li>
    

    我们来分析下这种情况下的流程:

    1. 对比第一项key都是1,内容不变,不处理
    2. 对比第二项key都是2,内容不变,不处理
    3. 第三项key为3的是新的,新增
    4. 第四项key为4的是新的,新增

    这个例子中我们使用索引(+1)作为key,没有什么问题,完全符合我们的预期。接下我们看第二个

    假设我们的的列表数据从

    
    [
        {id:2,text:'b'},
        {id:3,text:'c'},
        {id:5,text:'e'}
    ]
    

    变成了

    
    [
        {id:1,text:'a'},
        {id:2,text:'b'},
        {id:3,text:'c'},
        {id:4,text:'d'}
    ]
    

    仍然使用索引作为key,那么渲染出来的应该是

    旧的

    
    <li key={1}>b</li>
    <li key={2}>c</li>
    <li key={3}>e</li>
    

    新的

    
    <li key={1}>a</li>
    <li key={2}>b</li>
    <li key={3}>c</li>
    <li key={4}>d</li>
    

    这种情况下的流程:

    1. 对比第一项key都是1,但是内容变了,替换文本
    2. 对比第二项key都是2,但是内容变了,替换文本
    3. 对比第三项key都是3,但是内容变了,替换文本
    4. 第四项key为4是新的,新增

    这个和我们想的就有区别了,因为我们只是想做两步操作,即替换第1个和添加第4个。而现在做了四步操作。

    也许这个例子显得没有那么糟糕,但是想象一下,如果是在一个50项的列表中插入1个新的到头部,那么后面的50项将都会进行dom更新渲染,如果每一项内容是复杂的组件,那么代价更加高昂,而我们其实只是想在第一个元素前插入一条。

    那么如果解决上面的问题呢,其实很简单,我们的列表数据都有唯一的id值,而实际开发中我们列表中一般都会存在这样的唯一值,我们只需要把它复制给key即可

    那么我们的列表会变成这样

    旧的

    
    <li key={2}>b</li>
    <li key={3}>c</li>
    <li key={5}>e</li>
    

    新的

    
    <li key={1}>a</li>
    <li key={2}>b</li>
    <li key={3}>c</li>
    <li key={4}>d</li>
    

    这种情况下的流程:

    1. 第一项key为1是新的,新增,节点变成4个
    2. 对比第二项key都是2,内容不变,不处理
    3. 对比第三项key都是3,内容不变,不处理
    4. 第四项key为4,旧的是5,替换节点

    将列表和列表项单独写成纯组件

    为什么?

    我们可能已经习惯这样写列表

    
    render(){
        render (
            <ul>
                {this.state.list.map(item=><li key={item.id}>{item.text}<li>)}
            </ul>
        )
    }
    

    在大多数情况下,这样写没有什么问题,reactjs执行速度很快,但是有些情况下,这样写可能成为导致网页卡顿的罪魁祸首。

    每当我们改变组件状态的时候,reactjs都会重建当前组件的整个虚拟dom树,也就是说不管你的state.list是否有改变,整个树都会重建,而这个时候列表的渲染是不必要的,当列表过长,组件状态更新频繁,甚至手机性能不佳的情况下,不断的重新创建虚拟dom树很有可能会导致页面帧数下降。

    PureComponent

    PureComponentComponent没什么什么区别,除了它默认在shouldUpdateComponent里面默认做了浅比较,如果相同,则不会触发更新渲染。

    reactjs中,数据推荐处理成不可变数据(这里不是指immutable.js,而是说对象始终是不变的,如果数据有变了,必须是新的对象),配合redux的时候更是如此。所以如果list发生改变时,传入的必然是新的对象,这个时候会触发列表组件更新。

    使用

    
    class List extends PureComponent{
        render(){
            return (
                <ul>
                {this.props.list.map(item=><li key={item.id}>{item.text}<li>)}
            </ul>
            )
        }
    }
    
    /*** parent ***/
    // .....
    render(){
        render (
            <List list = {this.state.list}/>
        )
    }
    // ...
    

    子组件

    当我们列表的子元素是复杂的组建时,我们也应该单独提取成PureComponent,以避免不必要的渲染,事实上,我觉得大多数组件都可以使用PureComponent替换Component

    不要在属性上箭头函数

    箭头函数很方便,不仅写法简单还能保持this指向父级作用域。

    为了维护事件处理函数的this,我们经常在组件中看到它类似这样的使用

    
    <Component onClick={()=>{alert(11)} />
    

    但是这样写会有几个问题

    1. 每次render都会重新创建一个新的函数,浏览器创建和回收对象都会有开销,如果是列表,那么每个列表项都会创建和销毁。
    2. 因为每次render都是传入新的函数,shouldUpdateComponent浅比较必然不相等,会导致PureComponent组件失去应有效果。

    正确的做法

    如果使用了transform-class-properties

    
    handleClick = ()=>{
        alert(1)
    }
    
    
    <Component onClick={this.handleClick} />
    

    或者

    
    constructor(){
        super(...arguments)
        this.handleClick = this.handleClick.bind(this)
    }
    
    handleClick = ()=>{
        alert(1)
    }
    

    结束语

    暂时就总结了这些吧,以后有新的心得再更新,欢迎交流留言。

    来源:https://segmentfault.com/a/1190000011191890

  • 相关阅读:
    在不同的浏览器下FORM及它的小伙伴们默认样式的CSS属性值是不全然一致
    思考博客园的机器人攻击,想到我们可能也需要开启iptables
    大数据量的Mysql数据库备份策略
    win7或win2008系统中,出现【已停止工作,联机检查解决方案并关闭该程序,关闭程序】解决方法!
    Mysql的碎片查看与处理
    "个性化空间"性能优化方案设计初步
    假期结束后的工作安排
    GZIP压缩占用CPU大吗?
    媒体云平台
    关于二级缓存的设计思路
  • 原文地址:https://www.cnblogs.com/datiangou/p/10161730.html
Copyright © 2020-2023  润新知