react性能優(yōu)化達(dá)到最大化的方法 immutable.js使用的必要性

更新時(shí)間：2021年09月09日 08:52:09 作者：楊川寶

這篇文章主要為大家詳細(xì)介紹了react性能優(yōu)化達(dá)到最大化的方法，一步一步優(yōu)化react性能的過程，告訴大家使用immutable.js的必要性，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下

一行代碼勝過千言萬語。這篇文章呢，主要講述我一步一步優(yōu)化react性能的過程，為什么要用immutable.js呢。毫不夸張的說。有了immutable.js（當(dāng)然也有其他實(shí)現(xiàn)庫）。。才能將react的性能發(fā)揮到極致！要是各位看官用過一段時(shí)間的react，而沒有用immutable那么本文非常適合你。那么我開始吧！

1、對(duì)于react的來說，如果父組件有多個(gè)子組件

想象一下這種場(chǎng)景，一個(gè)父組件下面一大堆子組件。然后呢，這個(gè)父組件re－render。是不是下面的子組件都得跟著re－render?？墒呛芏嘧咏M件里面是冤枉的啊！很多子組件的props 和 state 然而并沒有改變?。?！雖然virtual dom 的diff 算法很快，但是性能也不是這么浪費(fèi)的??！下面我們上代碼

1）.原始代碼如下

以下是父組件代碼。。負(fù)責(zé)輸入name 和 age 然后循環(huán)顯示name 和 age

 export default class extends Component {
  constructor(props){
  super(props)
  this.state={
   name:"",
   age :"",
   persons:[]
  }
  }
  render() {
  const {name,age,persons} = this.state
  return (
   <div>
   <span>姓名:</span><input value={name} name="name" onChange={this._handleChange.bind(this)}></input>
   <span>年齡:</span><input value={age} name="age" onChange={this._handleChange.bind(this)}></input>
   <input type="button" onClick={this._handleClick.bind(this)} value="確認(rèn)"></input>
   {persons.map((person,index)=>(
    <Person key={index} name={person.name} age={person.age}></Person>
   ))}
   </div>
  )
  }
  _handleChange(event){
  this.setState({[event.target.name]:event.target.value})
  }
  _handleClick(){
  const {name,age} = this.state
  this.setState({
   name:"",
   age :"",
   persons:this.state.persons.concat([{name:name,age:age}])
  })
 
  }
 }

以下是子組件代碼單純的顯示name和age而已

class Person extends Component {
 componentWillReceiveProps(newProps){
 console.log(`我新的props的name是${newProps.name}，age是${newProps.age}。我以前的props的name是${this.props.name}，age是${this.props.age}是我要re-render了`);
 }
 render() {
 const {name,age} = this.props;

  return (
  <div>
   <span>姓名:</span>
   <span>{name}</span>
   <span> age:</span>
   <span>{age}</span>
  </div>
  )
 }
}

運(yùn)行起來長下圖這個(gè)樣

好那么問題來了，我們看一下控制臺(tái)：

天哪，這么多次re-reder..細(xì)細(xì)觀看，不難發(fā)現(xiàn)。要re-render這么多次，父組件一re-render,子組件就跟著re-render啊。那么多么浪費(fèi)性能，好PureRenderMixin出場(chǎng)

2）.PureRenderMixin

因?yàn)樵塾玫氖莈s2015的 Component，所以已經(jīng)不支持mixin了，不過沒關(guān)系，可以用HOCs，這個(gè)比mixin還更受推崇呢。我有空回用代碼來展示他倆的異同，鑒于不是本文重點(diǎn)，，大家可以看這兩篇文章了解下React Mixin 的前世今生和Mixins Are Dead. Long Live Composition

所以在這里我們用Pure render decorator代替PureRenderMixin，那么代碼如下

import pureRender from "pure-render-decorator"
...

@pureRender
class Person extends Component {
 render() {
 console.log("我re-render了");
 const {name,age} = this.props;

  return (
  <div>
   <span>姓名:</span>
   <span>{name}</span>
   <span> age:</span>
   <span>{age}</span>
  </div>
  )
 }
}

加個(gè)這東西就完事了？看上去咋這么不令人信服啊。不管怎樣，試試吧。

果然可以做到pure render，在必須render 的時(shí)候才render。

好我們看看它的神奇之處

@pureRender

是es7的Decorators語法。上面這么寫就和下面這么寫一樣

class PersonOrigin extends Component {
 render() {
 console.log("我re-render了");
 const {name,age} = this.props;

  return (
  <div>
   <span>姓名:</span>
   <span>{name}</span>
   <span> age:</span>
   <span>{age}</span>
  </div>
  )
 }
}
const Person = pureRender(PersonOrigin)

pureRender其實(shí)就是一個(gè)函數(shù)，接受一個(gè)Component。把這個(gè)Component搞一搞，返回一個(gè)Component看他pureRender的源代碼就一目了然

function shouldComponentUpdate(nextProps, nextState) {
 return shallowCompare(this, nextProps, nextState);
}

function pureRende(component) {
 component.prototype.shouldComponentUpdate = shouldComponentUpdate;
}
module.exports = pureRender;

pureRender很簡單，就是把傳進(jìn)來的component的shouldComponentUpdate給重寫掉了，原來的shouldComponentUpdate，無論怎樣都是return ture，現(xiàn)在不了，我要用shallowCompare比一比，shallowCompare代碼及其簡單，如下

function shallowCompare(instance, nextProps, nextState) {
 return !shallowEqual(instance.props, nextProps) || !shallowEqual(instance.state, nextState);
}

一目了然。分別拿現(xiàn)在props&state和要傳進(jìn)來的props&state，用shallowEqual比一比，要是props&state都一樣的話，就return false，是不是感覺很完美？不。。這才剛剛開始，問題就出在shallowEqual上了

3）.shallowEqual的問題

shallowEqual引起的bug
很多時(shí)候，父組件向子組件傳props的時(shí)候，可能會(huì)傳一個(gè)復(fù)雜類型，比如我們改下。

 render() {
 const {name,age,persons} = this.state
 return (
  <div>
...省略.....
  {persons.map((person,index)=>(
   <Person key={index} detail={person}></Person>
  ))}
  </div>
 )
 }

person是一個(gè)復(fù)雜類型。這就埋下了隱患，在演示隱患前，我們先說說shallowEqual，是個(gè)什么東西，shallowEqual其實(shí)只比較props的第一層子屬性是不是相同，就像上述代碼，props 是如下

{
 detail:{
  name:"123",
  age:"123"}
}

他只會(huì)比較props.detail ===nextProps.detail
那么問題來了，上代碼
如果我想修改detail的時(shí)候考慮兩種情況

情況一，我修改detail的內(nèi)容，而不改detail的引用

這樣就會(huì)引起一個(gè)bug，比如我修改detail.name,因?yàn)閐etail的引用沒有改，所以props.detail ===nextProps.detail 還是為true。
所以我們?yōu)榱税踩鹨姳仨毿薷膁etail的引用，（redux的reducer就是這么做的）

情況二，我修改detail的引用

這種雖然沒有bug，但是容易誤殺，比如如果我新舊兩個(gè)detail的內(nèi)容是一樣的，豈不是還要，render。所以還是不完美，你可能會(huì)說用深比較就好了，但是深比較及其消耗性能，要用遞歸保證每個(gè)子元素一樣。

這只是說沒有用immutable引起各種、、、下一篇我講寫，如何用immutable.j。

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

您可能感興趣的文章: