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

PureComponent和Component沒什麼什麼區別，除了它默認在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)
}

結束語

暫時就總結了這些吧，之後有新的心得再更新，歡迎交流留言。