react阻止無效重渲染的多種方式

在開發React組件的過程當中，咱們常常會遇到這個問題：什麼狀況下組件會從新渲染？

　　當內部data發生改變，state發生改變(經過調用this.setState()) 以及父組件傳過來的props發生改變時，會致使組件從新渲染。

如下幾個問題一樣值得咱們思考：
　　setState()函數在任何狀況下都會致使組件重渲染嗎？若是setState中的state沒有發生改變呢？
　　若是state和從父組件傳過來的props都沒變化，那他就必定不會發生重渲染嗎？

首先，咱們來解決這兩個問題
　　沒有致使state的值發生變化的this.setState(）是否會致使重渲染      ---  會 

import React from 'react'
class Test extends React.Component{
  constructor(props) {
    super(props);
    this.state = {
      Number:1//設state中Number值爲1
    }
  }
  //這裏調用了setState可是並無改變setState中的值
  handleClick = () => {
     const preNumber = this.state.Number
     this.setState({
        Number:this.state.Number
     })
  }
  render(){
    //當render函數被調用時，打印當前的Number
    console.log(this.state.Number)
    return(<h1 onClick = {this.handleClick}>
             {this.state.Number}
           </h1>)
  }
}

從控制檯的打印結果能夠看出：共打印了15次1，可是組件並無發生任何變化！！！

 這樣的結果不是咱們想要的，如何阻止組件的重渲染呢？這時咱們想到了React的一個生命週期鉤子 shouldComponentUpdate

 

react生命週期中有這樣一個鉤子，叫shouldComponentUpdate函數，是重渲染時render()函數調用前被調用的函數，

　　兩個參數 nextProps和nextState ，分別表示下一個props和state的值。

　　當函數返回false時，阻止接下來的render()函數的調用，阻止組件重渲染，返回true時，組件照常渲染

 

 //加入shouldComponentUpdate鉤子
//在render函數調用前判斷：若是先後state中Number不變，經過return false阻止render調用
  shouldComponentUpdate(nextProps,nextState){
      if(nextState.Number == this.state.Number){
        return false
      }
  }
加入上述代碼後，打開控制檯，點擊按鈕，仍是白白的，說明無效的重渲染被咱們阻止了

 

第二個問題，組件的state和從父組件傳遞過來的props都沒改變，組件還會重渲染嗎 ---可能
　　一樣能夠經過shouldComponentUpdate鉤子進行阻止

因此說，先後不改變state的值的setState和無數據交換的父組件的重渲染都會致使組件的重渲染，但咱們能夠經過shouldComponentUpdate來阻止這兩種狀況
shouldComponentUpdate並非完美的，只能阻止扁平的對象

 

nextState.Number == this.state.Number
若是調用層次比較深
nextState.NumberObject.number == this.state.NumberObject.number
Number 是一個數字變量
NumberObject是一個對象
數字變量(number類型)和對象(Object)類型的內存存儲機制不一樣
這時候，由於二者都指向堆中的同一個對象，因此一直都是true  shouldComponentUpdate失效了
js變量分爲基本類型的變量和引用類型的變量

　　對於number,string,boolean,undefined,null這些基本類型變量，值存在棧中
　　對於object,Array,function這些引用類型變量，引用存在棧中，而不一樣的引用卻能夠指向堆內存中的同一個對象

 那麼，問題就來了

怎麼樣才能取到不一樣的NumberObject呢？
四種方法：
　　一、ES6的擴展語法Object.assign()
　　二、深拷貝/淺拷貝或利用JSON.parse(JSON.stringify(data))至關於深拷貝，但使用受必定限制
　　三、引入immutable.js react官方推薦的第三方庫
　　四、繼承react的PureComponent組件（代替Component）

 

在js中，引用類型的數據，優勢在於頻繁的操做數據都是在原對象的基礎上修改，不會建立新對象，從而能夠有效的利用內存，不會浪費內存，這種特性稱爲mutable（可變），但偏偏它的優勢也是它的缺點，太過於靈活多變在複雜數據的場景下也形成了它的不可控性，假設一個對象在多處用到，在某一處不當心修改了數據，其餘地方很難預見到數據是如何改變的，針對這種問題的解決方法，通常就像剛纔的例子，會想複製一個新對象，再在新對象上作修改，這無疑會形成更多的性能問題以及內存浪費。
  爲了解決這種問題，出現了immutable對象，每次修改immutable對象都會建立一個新的不可變對象，而老的對象不會改變。

immutable.js主要有三大特性：
Persistent data structure （持久化數據結構）
structural sharing （結構共享）
support lazy operation （惰性操做）

 

Immutable Data 就是一旦建立，就不能再被更改的數據。對 Immutable 對象的任何修改或添加刪除操做都會返回一個新的 Immutable 對象。Immutable 實現的原理是 Persistent Data Structure（持久化數據結構），也就是使用舊數據建立新數據時，要保證舊數據同時可用且不變。同時爲了不 deepCopy 把全部節點都複製一遍帶來的性能損耗，Immutable 使用了 Structural Sharing（結構共享），即若是對象樹中一個節點發生變化，只修改這個節點和受它影響的父節點，其它節點則進行共享

三個最重要的數據結構： Map List Set
Map：鍵值對集合，對應於 Object，ES6 也有專門的 Map 對象
List：有序可重複的列表，對應於 Array
Set：無序且不可重複的列表

 

//Map()  原生object轉Map對象 (只會轉換第一層，注意和fromJS區別)
immutable.Map({name:'danny', age:18})

//List()  原生array轉List對象 (只會轉換第一層，注意和fromJS區別)
immutable.List([1,2,3,4,5])

//fromJS()   原生js轉immutable對象  (深度轉換，會將內部嵌套的對象和數組所有轉成immutable)
immutable.fromJS([1,2,3,4,5])    //將原生array  --> List
immutable.fromJS({name:'danny', age:18})   //將原生object  --> Map

//toJS()  immutable對象轉原生js  (深度轉換，會將內部嵌套的Map和List所有轉換成原生js)
immutableData.toJS();

//查看List或者map大小  
immutableData.size  或者 immutableData.count()

// is()   判斷兩個immutable對象是否相等
immutable.is(imA, imB);

//merge()  對象合併
var imA = immutable.fromJS({a:1,b:2});
var imA = immutable.fromJS({c:3});
var imC = imA.merge(imB);
console.log(imC.toJS())  //{a:1,b:2,c:3}
對於兩個同樣的數據，只有經過equals進行比較纔是相等的  ==  ===都不行
若是 某個是另外一個克隆出來的，那麼所有都相等
push添加 unshift在頭部添加 concat組合  返回的是新數據，而不是數據的長度
//增刪改查（全部操做都會返回新的值，不會修改原來值）
var immutableData = immutable.fromJS({
    a:1,
    b:2，
    c:{
        d:3
    }
});
var data1 = immutableData.get('a') //  data1 = 1  
var data2 = immutableData.getIn(['c', 'd']) // data2 = 3   getIn用於深層結構訪問
var data3 = immutableData.set('a' , 2);   // data3中的 a = 2
var data4 = immutableData.setIn(['c', 'd'], 4);   //data4中的 d = 4
var data5 = immutableData.update('a',function(x){return x+4})  //data5中的 a = 5
var data6 = immutableData.updateIn(['c', 'd'],function(x){return x+4}) //data6中的 d = 7
var data7 = immutableData.delete('a')   //data7中的 a 不存在
var data8 = immutableData.deleteIn(['c', 'd'])   //data8中的 d 不存在複製代碼

 

優勢：
　　下降immutable帶來的複雜度
　　節省內存
　　歷史追溯性（時間旅行）：時間旅行指的是，每時每刻的值都被保留了，想回退到哪一步只要簡單的將數據取出就行，想一下若是如今頁面有個撤銷的操做，撤銷前的數據被保留了，只須要取出就行，這個特性在redux或者flux中特別有用
　　擁抱函數式編程：immutable原本就是函數式編程的概念，純函數式編程的特色就是，只要輸入一致，輸出必然一致，相比於面向對象，這樣開發組件和調試更方便

缺點：
　　須要從新學習api
　　資源包大小增長（源碼5000行左右）
　　容易與原生對象混淆：因爲api與原生不一樣，混用的話容易出錯。

 碼字不易，引用請註明出處！  ---拈花煮酒

http://www.cnblogs.com/luxiaot/p/10097572.html