js 對象深拷貝
JS 里面的變量類型可以分為 基本類型 和 引用類型 这敬。
在使用過程中航夺，引用類型經(jīng)常會產(chǎn)生一些無法意識到的副作用，所以在現(xiàn)代 JS 開發(fā)過程中崔涂，有經(jīng)驗的開發(fā)者都會在特定位置有意識的寫下斷開引用的不可變數(shù)據(jù)類型阳掐。
// 因為引用所帶來的副作用：
var a = [{ val: 1 }]
var b = a.map(item => item.val = 2)
// 期望：b 的每一個元素的 val 值變?yōu)?2，但最終 a 里面每個元素的 val 也變?yōu)榱?2
console.log(a[0].val) // 2
在發(fā)現(xiàn)這樣的問題之后冷蚂，解決方案也很簡單缭保。一般來說當需要傳遞一個引用類型的變量（例如對象）進一個函數(shù)時，我們可以使用 Object.assign 或者 ... 對對象進行解構蝙茶，成功斷掉一層的引用艺骂。 例如上面的問題我們可以改用下面的這種寫法：
var a = [{ val: 1 }]
var b = a.map(item => ({ ...item, val: 2 }))
console.log(a[0].val) // 1
console.log(b[0].val) // 2
對于深層級的對象我們可以實現(xiàn)一個遞歸方法來實現(xiàn)對象的深拷貝
function deepClone(obj) {
const keys = Object.keys(obj)
return keys.reduce((memo, current) => {
const value = obj[current]
if (typeof value === 'object') {
// 如果當前結果是一個對象，那我們就繼續(xù)遞歸這個結果
return {
...memo,
[current]: deepClone(value),
}
}
return {
...memo,
[current]: value,
}
}, {})
}
但是往往在實際的開發(fā)過程中這樣的方法并無法覆蓋所有情況
- key 里面 getter隆夯，setter 以及原型鏈上的內容
- value 是一個 Symbol
- value 內部出現(xiàn)了一些循環(huán)引用等
- 頻繁的遞歸會對性能造成很大的影響
immutable.js
immutable-js 使用了另一套數(shù)據(jù)結構的 API 钳恕，與我們的常見操作有些許不同，它將所有的原生數(shù)據(jù)類型（Object蹄衷， Array等）都會轉化成 immutable-js 的內部對象（Map忧额，List 等），并且任何操作最終都會返回一個新的 immutable 的值宦芦。
const { fromJS } = require('immutable')
const data = {
val: 1,
desc: {
text: 'a',
},
}
const a = fromJS(data)
const b = a.set('val', 2)
console.log(a.get('val')) // 1
console.log(b.get('val')) // 2
const pathToText = ['desc', 'text']
const c = a.setIn([...pathToText], 'c')
console.log(a.getIn([...pathToText])) // 'a'
console.log(c.getIn([...pathToText])) // 'c'
在 immutable-js 的數(shù)據(jù)結構中宙址，深層次的對象 在沒有修改的情況下仍然能夠保證嚴格相等，這也是 immutable-js 的另一個特點 「深層嵌套對象的結構共享」调卑。即嵌套對象在沒有改動前仍然在內部保持著之前的引用抡砂，修改后斷開引用大咱，但是卻不會影響之前的結果。
但是由于immutable的api與js的原生api有不少的出入注益，因此在使用和遷移的現(xiàn)有代碼過程的時候有較高的成本碴巾。
immer.js
與 immutable-js 最大的不同，immer 是使用原生數(shù)據(jù)結構的 API 而不是像 immutable-js 那樣轉化為內置對象之后使用內置的 API
const produce = require('immer')
const state = { done: false, val: 'string', }
const newState = produce(state, (draft) => {
draft.done = true
})
console.log(state.done) // false
console.log(newState.done) // true
通過上面的例子我們能發(fā)現(xiàn)丑搔，所有具有副作用的邏輯都可以放進 produce 的第二個參數(shù)的函數(shù)內部進行處理厦瓢。在這個函數(shù)內部對原來的數(shù)據(jù)進行任何操作，都不會對原對象產(chǎn)生任何影響啤月。
這里我們可以在函數(shù)中進行任何操作煮仇，例如 push splice 等非 immutable 的 API，最終結果與原來的數(shù)據(jù)互不影響谎仲。
總結
- Immer 的 API 非常簡單浙垫，上手幾乎沒有難度，同時項目遷移改造也比較容易郑诺。immutable-js 上手就復雜的多夹姥，使用 immutable-js 的項目遷移或者改造起來會稍微復雜一些。
- Immer 需要環(huán)境支持 Proxy 和 defineProperty辙诞，否則無法使用辙售。但 immutable-js 支持編譯為 ES3 代碼，適合所有 JS 環(huán)境飞涂。
- Immer 的運行效率受到環(huán)境因素影響較大旦部。immutable-js 的效率整體來說比較平穩(wěn)，但是在轉化過程中要先執(zhí)行 fromJS 和 toJS封拧，所以需要一部分前期效率的成本志鹃。
