Reactjs 列表优化的一些心得。

前言

在应用开发中,列表是咱们使用频率很是高的一种展示形式,在reactjs项目中更是如此。无处不在的使用更是须要咱们当心触发性能瓶颈的深水炸弹。javascript

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

不要用索引当key

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

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

在列表中,元素类型通常是相同的,因此咱们须要根据惟一的key值来给当前元素加上标记,这样reactjs才能感知元素是否须要增长或删除了。git

reactjs采用的很是直接粗暴的算法来判断元素的增删,好比github

旧的算法

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

新的redux

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

咱们来分析下这种状况下的流程:api

  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)
}

结束语

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

相关文章
相关标签/搜索