假設 React 組件有這樣一個狀態(tài)：

this.state = {
    a: {
        b: 1
    }
}

我們這樣修改了它的狀態(tài)：

this.state.a.b = 2;
this.setState(this.state);

你覺得組件會重新渲染么？

我們先在 class 組件里試一下：

import { Component } from 'react';

class Dong extends Component {
    constructor() {
        super();

        this.state = {
            a: {
                b: 1
            }
        }
    }

    componentDidMount() {
        setTimeout(() => {
            this.state.a.b = 2;
            this.setState(this.state);
        }, 2000);
    }
    render() {
        return <div>{this.state.a.b}</div>
    }
}

export default Dong;

渲染 state.a.b 的值，兩秒以后修改 state。

你發(fā)現(xiàn)它重新渲染了，因為普通的 class 組件只要 setState 就會渲染。

但很多情況下我們需要做性能優(yōu)化，只有 props 和 state 變了才需要渲染，這時候會繼承 PureComponent：

但這時候你就會發(fā)現(xiàn)組件不再重新渲染了。

說明這種情況下不能這樣寫 setState：

先不著急探究原因，我們再在 function 組件里試一下：

import { useEffect, useState } from 'react';

function Dong() {
    const [state, setState] = useState({
        a: {
            b: 1
        }
    });

    useEffect(() => {
        setTimeout(() => {
            state.a.b = 2;
            setState(state)
        }, 2000);
    }, [])
    return <div>{state.a.b}</div>
}

export default Dong;

這時候你覺得組件會重新渲染么？

結果是也不會重新渲染。

這說明 React 內部肯定對 function 組件還有繼承 PureComponent 的 class 組件做了相應的處理。

那 React 都做了什么處理呢？

我們從源碼看一下：

首先是繼承 PureComponent 的 class 組件：

你會發(fā)現(xiàn) React 在更新 class 組件的時候，會判斷如果是 PureComponent，那么會淺比較 props 和 state，如果變了才會渲染。

怎么淺比較的呢？

你會發(fā)現(xiàn)它先對比了兩個值是否相等，如果不相等的話，再取出 key 來，對比每個 key 的值是否相等。

所以說，我們 setState 的時候傳入 this.state 就不行了，第一個判斷都過不去。

而且就算創(chuàng)建了新對象，如果每個 key 的值沒有變，那依然也是不會渲染的。

這就是 React 對 PureComponent 做的優(yōu)化處理。

再來看下 function 組件的，React 是怎么對它做的處理呢？

你會看到調用 useState 的 setXxx 時，React 會判斷上次的 state 和這次的 state，如果一樣，那就不會渲染，直接 return 了。

這是為什么 function 組件里 setState 上次的 state 不行的原因。

這兩種情況還是有區(qū)別的，PureComponent 的處理里如果 state 變了，還會依次對比每個 key 的值，如果有某個值變了才會去渲染，但 function 組件里只對比了 state。

我們測試一下：

用上圖的方式 setState，整個 state 變了，但是 key 對應的值沒有變。

在 PureComponent 的 class 組件里，按照我們的分析應該不會再渲染，只會打印一次 render：

確實是這樣，雖然 state 對象變了，但是 key 的值沒變，不會重新渲染。

然后在 function 組件里試一下：

你會發(fā)現(xiàn)它打印了兩次 render：

綜上，我們可以總結一下：

普通的 class 組件，setState 就會重新渲染

繼承 PureComponent 的 class 組件，setState 時會對比 state 本身變沒變，還會對比 state 的每個 key 的值變沒變，變了才會重新渲染

function 組件在用 useState 的 setXxx 時，會對比 state 本身變沒變，變了就會重新渲染

為什么 function 組件里只對比了 state 沒有對比每個 key 的值也很容易理解，因為本來每個 state就是用 useState 單獨聲明的了，不像 class 組件的 state 都在一起。

知道了這個結論，我們也就知道了 setState 該怎么寫了：

class 組件要這么寫：

state 的每個要修改的 key 的值，如果是個對象，那要創(chuàng)建一個新的對象才行。

function 組件里也是，要這么寫：

綜上，不管是 class 組件，還是 function 組件，setState 時都要創(chuàng)建新的 state，并且對應的 key 的值的時候，如果是對象，要創(chuàng)建新的對象（雖然普通 class 組件里可以不這么寫，但還是建議統(tǒng)一用這種寫法，不然容易引起困惑）。

但這樣又有了一個新的問題：

如果 state 的內容很多呢？

而你只想修改其中的一部分，要把整個對象復制一次：

是不是很麻煩？

能不能我修改了對象的值，立馬給我返回一個新的對象呢？

就是最開頭的時候，我們的那種寫法改造一下：

const newState = this.state.set('a.b', 2);

this.setState(newState);

這么一個明顯的痛點需求，自然就有相應的庫了，也就是 immutable，這個是 facebook 官方出的，說是花了三年寫的。

它有這么幾個 api：fromJS、toJS、set、setIn、get、getIn。

我們試一下就知道了：

const immutableObj = fromJS({
    a: {
        b: 1
    }
});
const newObj = immutableObj.get('a').set('b', 2);

用 fromJS 把 JS 對象轉成 immutable 內部的數(shù)據(jù)結構，然后 get a，再 set b 的值。

這樣返回的是 immutable 的數(shù)據(jù)結構，并且對 b 做了修改：

你和之前的 a 屬性的值對比下，發(fā)現(xiàn)也不一樣了：

這就是它的作用，修改值以后返回新的 immutable 數(shù)據(jù)結構。

那如果像修改一個層數(shù)比較深的值，但希望返回的值是整個對象的新的 immutable 結構呢？

可以用 setIn：

這樣修改了任意屬性之后，都能拿到最新的對象，這不就完美解決了我們的痛點問題么？

你還可以用 toJS 再把 immutable 數(shù)據(jù)結構轉成 JS 對象：

再來回顧下 immutable 的 api：fromJS、toJS、set、get、setIn、getIn 這些都很容易理解。再就是 immutable 內部的數(shù)據(jù)結構 Map、Set 等。（注意這里的 Map、Set 不是 JS 里的那個，而是 immutable 實現(xiàn)的）

這些 immutable 數(shù)據(jù)結構一般不大需要手動創(chuàng)建，直接用 fromJS 讓 immutable 去創(chuàng)建就行。

然后我們在 React 組件里用一下試試：

先在 class 組件里用用：

a 的值是個對象，我們用 fromJS 轉成 immutable 的數(shù)據(jù)結構，之后修改調用 set、setIn 來修改。

不過，渲染的時候也得用 get、getIn 的 api 來取了。

這樣也解決了 setState 需要創(chuàng)建新對象的問題，而且更優(yōu)雅。

有的同學可能會問，為什么要 sate.a 用 fromJS 轉成 immutable，而不是整個 state 呢？

因為 react 內部也會用到這個 state 呀，就比如上面那個淺比較那里：

react 需要把每個 key 的值取出來對比下變沒變，而 immutable 對象只能用 get、getIn 來取，所以class 組件里不能把整個 state 變?yōu)?immutable，只能把某個 key 值的對象變?yōu)?immutable。

再在 function 組件里用下：

function 組件里就可以這樣寫了，把整個 state 用 fromJS 變?yōu)?immutable 的，然后后面修改用 setIn，獲取用 getIn。

也同樣解決了 setState 要創(chuàng)建新對象的問題。

為啥 function 組件里就可以把整個 state 變?yōu)?immutable 的了呢？

因為只有組件內部會用呀，我們自己寫的代碼是知道用 setIn、getIn 來操作的，但是 class 組件的話 react 還會對 PureComponent 做一些優(yōu)化，會在組件外把 state 取出來處理，所以那個就只能把某些 key 變?yōu)?immutable 了。

immutable 介紹完了，大家覺得怎么樣？

immutable 確實解決了創(chuàng)建新對象的復雜度的問題，而且性能也好，因為它創(chuàng)建了一套自己的數(shù)據(jù)結構。

但也相應的，導致使用的時候必須要用 getIn、setIn 的 api 才行，有一些心智負擔。

這種心智負擔是不可避免的吧？

還真可以，這幾年又出了一個新的 immutable 庫，叫做 immer（MobX 作者寫的）。它就覆蓋了 immutable 的功能的同時，還沒有心智負擔。

沒有心智負擔？怎么可能？

我們試一下就知道了：

import { produce } from 'immer';

const obj = {
    a: {
        b: 1
    }
};

const obj2 = produce(obj, draft => {
    draft.a.b = 2 
});

obj 是原對象，調用 produce 傳入該對象和要對它做的修改，返回值就是新對象：

后面就是普通 JS 對象的用法，也不用啥 getIn、setIn 啥的。

我們在 class 組件里用一下：

setState 的時候調用 produce，傳入原來的 state 和修改函數(shù)，這樣返回的就是新的 state。

用 state 的時候依然是普通 JS 對象的用法。是不是簡單的一批，心智負擔基本為 0？

我們再在 function 組件里用一下：

同樣簡單的一批，只要 setState 的時候調用下 produce 來產(chǎn)生新對象就行。

又學完了 immer，我們來對比下 immutable 和 immer：

直接看圖吧：

class 組件里，immutable 這樣寫：

immer 這樣寫：

function 組件里，immutable 這樣寫：

immer 這樣寫：

沒有對比就沒有傷害，從使用體驗上，immer 完勝。

這么說，我們只用 immer 不就行了？

也不全是，90% 的場景下用 immer 就行，但 immutable 也有它獨特的優(yōu)點：

immutable 有自己的數(shù)據(jù)結構，修改數(shù)據(jù)的時候會創(chuàng)建新的節(jié)點連接之前的節(jié)點組成新的數(shù)據(jù)結構。

而 immer 沒有自己的數(shù)據(jù)結構，它只是通過 Proxy 實現(xiàn)了代理，內部自動創(chuàng)建新的對象：

只不過是把手動創(chuàng)建新對象的過程通過代理給自動化了：

所以從性能上來說，如果有特別大的 state 的話，immutable 會好一些，因為他用的是專用數(shù)據(jù)結構，做了專門的優(yōu)化，除此以外，immer 更好一些。

綜上，90% 的 React 應用，用 immer 比 immutable 更好一些，代碼寫起來簡單，也更容易維護。有大 state 的，可以考慮 immutable。

此外，immutable 在 redux 里也很有用的：

用 immutable 的話是這樣寫：

const initialState = fromJS({})

function reducer(state = initialState, action) {
  switch (action.type) {
    case SET_NAME:
      return state.set('name', 'guang')
    default:
      return state
  }
}

取 store 的 state 要用 getIn 或 get：

function mapStateToProps(state) {
    return {
      xxxx: state.getIn(['guangguang', 'guang']),
      yyyy: state.getIn(['dongdong', 'dong'])
    }
  }

而 immer 是這樣寫：

const reducer = produce((state = initialState, action) => {
  switch (action.type) {
    case SET_NAME:
      state.name = 'guang';
      break;
    default:
      return state
  }
})

用 store 的 state 是普通對象的用法：

function mapStateToProps(state) {
    return {
      xxxx: state.guangguang,
      yyyy: state.dongdong
    }
}

從結合 redux 的角度來看，也是 immer 在體驗上完勝。

總結

在 React 組件里 setState 是要創(chuàng)建新的 state 對象的，在繼承 PureComponent 的 class 組件、function 組件都是這樣。

繼承 PureComponent 的 class 組件會淺對比 props 和 state，如果 state 變了，并且 state 的 key 的某個值變了，才會渲染。

function 組件的 state 對象變了就會重新渲染。

雖然在普通 class 組件里，不需要創(chuàng)建新的 state，但我們還是建議統(tǒng)一，所有的組件里的 setState 都創(chuàng)建新的對象。

但是創(chuàng)建對象是件比較麻煩的事情，要一層層 ...，所以我們會結合 immutable 的庫。

主流的 immutable 庫有兩個， facebook 的 immutable 和 MobX 作者寫的 immer。

immutable 有自己的數(shù)據(jù)結構，Map、Set 等，有 fromJS、toJS 的 api 用來轉換 immutable 數(shù)據(jù)結構和普通 JS 對象，操作數(shù)據(jù)需要用 set、setIn、get、getIn。

immer 只有一個 produce api，傳入原對象和修改函數(shù)，返回的就是新對象，使用新對象就是普通 JS 對象的用法。

從使用體驗上來說，不管是和 react 的 setState 結合還是和 redux 的 reducer 結合，都是 immer 完勝，但是 immutable 因為有專用數(shù)據(jù)結構的原因，在有大 state 對象的時候，性能會好一些。

90% 的情況下，immer 能完勝 immutable。