Immutable.js 以及在 react+redux 项目中的实践

来自一位美团大牛的分享，相信能够帮助到你。
原文连接：https://juejin.im/post/5948985ea0bb9f006bed7472?utm_source=tuicool&utm_medium=referral

前言

  本文主要介绍facebook推出的一个类库immutable.js，以及如何将immutable.js集成到咱们团队现有的react+redux架构的移动端项目中。

本文较长（5000字左右），建议阅读时间： 20 min

经过阅读本文，你能够学习到：

• 什么是immutable.js,它的出现能解决什么问题
• immutable.js的特性以及使用api
• 在一个redux+react的项目中，引入immutable.js能带来什么提高
• 如何集成immutable.js到react+redux中
• 集成先后的数据对比
• immutabe.js使用过程当中的一些注意点

目录

• 一. immutable.js
  • 1.1 原生js引用类型的坑
  • 1.2 immutable.js介绍
    • 1.2.1 Persistent data structure （持久化数据结构）
    • 1.2.2 structural sharing （结构共享）
    • 1.2.3 support lazy operation （惰性操做）
  • 1.3 经常使用api介绍
  • 1.4 immutable.js的优缺点
• 二. 在react+redux中集成immutable.js实践
  • 2.1 点餐H5项目引入immutable.js前的现状
  • 2.2 如何将immutableJS集成到一个react+redux项目中
    • 2.2.1 明确集成方案，边界界定
    • 2.2.2 具体集成代码实现方法
  • 2.3 点餐H5项目优化先后对比
• 三. immutable.js使用过程当中的一些注意点
• 四. 总结

一. immutable.js

1.1 原生js引用类型的坑

先考虑以下两个场景：

// 场景一
var obj = {a:1, b:{c:2}};
func(obj);
console.log(obj)  //输出什么？？

// 场景二
var obj = ={a:1};
var obj2 = obj;
obj2.a = 2;
console.log(obj.a);  // 2
console.log(obj2.a);  // 2复制代码

  上面两个场景相信你们平日里开发过程当中很是常见，具体缘由相信你们也都知道了，这边不展开细说了，一般这类问题的解决方案是经过浅拷贝或者深拷贝复制一个新对象，从而使得新对象与旧对象引用地址不一样。
  在js中，引用类型的数据，优势在于频繁的操做数据都是在原对象的基础上修改，不会建立新对象，从而能够有效的利用内存，不会浪费内存，这种特性称为mutable（可变），但偏偏它的优势也是它的缺点，太过于灵活多变在复杂数据的场景下也形成了它的不可控性，假设一个对象在多处用到，在某一处不当心修改了数据，其余地方很难预见到数据是如何改变的，针对这种问题的解决方法，通常就像刚才的例子，会想复制一个新对象，再在新对象上作修改，这无疑会形成更多的性能问题以及内存浪费。
  为了解决这种问题，出现了immutable对象，每次修改immutable对象都会建立一个新的不可变对象，而老的对象不会改变。

1.2 immutable.js介绍

  现今，实现了immutable数据结构的js类库有好多，immutable.js就是其中比较主流的类库之一。

Immutable.js出自Facebook，是最流行的不可变数据结构的实现之一。它从头开始实现了彻底的持久化数据结构，经过使用像tries这样的先进技术来实现结构共享。全部的更新操做都会返回新的值，可是在内部结构是共享的，来减小内存占用(和垃圾回收的失效)。

immutable.js主要有三大特性：

• Persistent data structure （持久化数据结构）
• structural sharing （结构共享）
• support lazy operation （惰性操做）

下面咱们来一一具体介绍下这三个特性：

1.2.1 Persistent data structure （持久化数据结构）

  通常听到持久化，在编程中第一反应应该是，数据存在某个地方，须要用到的时候就能从这个地方拿出来直接使用
  但这里说的持久化是另外一个意思，用来描述一种数据结构，通常函数式编程中很是常见，指一个数据，在被修改时，仍然可以保持修改前的状态，从本质来讲，这种数据类型就是不可变类型，也就是immutable
  immutable.js提供了十余种不可变的类型（List，Map，Set，Seq，Collection，Range等）
  到这，有些同窗可能会以为，这和以前讲的拷贝有什么区别，也是每次都建立一个新对象，开销同样很大。ok，那接下来第二个特性会为你揭开疑惑。

1.2.2 structural sharing （结构共享）

(图片来自网络)

immutable使用先进的tries(字典树)技术实现结构共享来解决性能问题，当咱们对一个Immutable对象进行操做的时候，ImmutableJS会只clone该节点以及它的祖先节点，其余保持不变，这样能够共享相同的部分，大大提升性能。

这边岔开介绍一下tries（字典树），咱们来看一个例子

(图片来自网络)
  图1就是一个字典树结构object对象，顶端是root节点，每一个子节点都有一个惟一标示（在immutable.js中就是hashcode）
  假设咱们如今取data.in的值，根据标记i和n的路径.能够找到包含5的节点.，可知data.in=5, 彻底不须要遍历整个对象
  那么，如今咱们要把data.tea从3修改为14，怎么作呢？
  能够看到图2绿色部分，不须要去遍历整棵树，只要从root开始找就行
  实际使用时，能够建立一个新的引用，如图3，data.tea建一个新的节点，其余节点和老的对象共享，而老的对象仍是保持不变
  因为这个特性，比较两个对象时，只要他们的hashcode是相同的，他们的值就是同样的，这样能够避免深度遍历

1.2.3 support lazy operation （惰性操做）

• 惰性操做 Seq
• 特征1：Immutable (不可变)
• 特征2：lazy（惰性，延迟）

这个特性很是的有趣，这里的lazy指的是什么？很难用语言来描述，咱们看一个demo，看完你就明白了

  这段代码的意思就是，数组先取奇数，而后再对基数进行平方操做，而后在console.log第2个数，一样的代码，用immutable的seq对象来实现，filter只执行了3次，但原生执行了8次。
  其实原理就是，用seq建立的对象，其实代码块没有被执行，只是被声明了，代码在get(1)的时候才会实际被执行，取到index=1的数以后，后面的就不会再执行了，因此在filter时，第三次就取到了要的数，从4-8都不会再执行
  想一想，若是在实际业务中，数据量很是大，如在咱们点餐业务中，商户的菜单列表可能有几百道菜，一个array的长度是几百，要操做这样一个array，若是应用惰性操做的特性，会节省很是多的性能

1.3 经常使用api介绍

//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}

//增删改查（全部操做都会返回新的值，不会修改原来值）
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 不存在复制代码

上面只列举了部分经常使用方法，具体查阅官网api:facebook.github.io/immutable-j…
immutablejs还有不少相似underscore语法糖，使用immutable.js以后彻底能够在项目中去除lodash或者underscore之类的工具库。

1.4 immutable.js的优缺点

优势：

• 下降mutable带来的复杂度
• 节省内存
• 历史追溯性（时间旅行）：时间旅行指的是，每时每刻的值都被保留了，想回退到哪一步只要简单的将数据取出就行，想一下若是如今页面有个撤销的操做，撤销前的数据被保留了，只须要取出就行，这个特性在redux或者flux中特别有用
• 拥抱函数式编程：immutable原本就是函数式编程的概念，纯函数式编程的特色就是，只要输入一致，输出必然一致，相比于面向对象，这样开发组件和调试更方便

缺点：

• 须要从新学习api
• 资源包大小增长（源码5000行左右）
• 容易与原生对象混淆：因为api与原生不一样，混用的话容易出错。

二. 在react+redux中集成immutable.js实践

  前面介绍了这么多，实际上是想引出这块重点，这章节会结合点评点餐团队在实际项目中的实践，给出使用immutable.js先后对react+redux项目的性能提高

2.1 点餐H5项目引入immutable.js前的现状

  目前项目使用react+redux，因为项目的不断迭代以及需求复杂度的提升，redux中维护的state结构日渐庞大，已经不是一个简单的平铺数据了，如菜单页state已经会出现三四层的object以及array嵌套，咱们知道，JS中的object与array是引用类型，在不断的操做过程当中，state通过屡次的action改变以后， 本来复杂state已经变得不可控，结果就是致使了一次state变化牵动了许多自身状态没有发生改动的component去re-render。以下图

  这里推荐一下react的性能指标工具react-addons-perf
  若是你没有使用这个工具看以前，别人问你，图中这个简单的堂食/外带的button的变化会引发哪些component去re-render，你可能会回答只有就餐方式这个component。
  但当你真正使用react-addons-perf去查看以后你会发现，WTF？？！一次操做居然致使了这么多没任何关系的component从新渲染了？？
   什么缘由？？

shouldComponentUpdate

shouldComponentUpdate (nextProps, nextState) {
   return nextProps.id !== this.props.id;
};复制代码

  相信接触过react开发的同窗都知道，react有个重要的性能优化的点就是shouldComponentUpdate，shouldComponentUpdate返回true代码该组件要re-render，false则不从新渲染
  那简单的场景能够直接使用==去判断this.props和nextProps是否相等，但当props是一个复杂的结构时，==确定是没用的
  网上随便查一下就会发现shallowCompare这个东西，咱们来试一下
使用shallowCompare的例子：

能够看到，其实2个对象的count是不相等的，但shallowCompare返回的仍是true
缘由：
  shallowCompare只是进行了对象的顶层节点比较，也就是浅比较，上图中的props因为结构比较复杂，在深层的对象中有count不同，因此这种状况没法经过shallowCompare处理。
shallowEqual源码：

function shallowEqual(objA, objB) {
  if (is(objA, objB)) {
    return true;
  }

  if (typeof objA !== 'object' || objA === null || typeof objB !== 'object' || objB === null) {
    return false;
  }

  var keysA = Object.keys(objA);
  var keysB = Object.keys(objB);

  if (keysA.length !== keysB.length) {
    return false;
  }
//这里只比较了对象A和B第一层是否相等，当对象过深时，没法返回正确结果
  // Test for A's keys different from B.
  for (var i = 0; i < keysA.length; i++) {
    if (!hasOwnProperty.call(objB, keysA[i]) || !is(objA[keysA[i]], objB[keysA[i]])) {
      return false;
    }
  }

  return true;
}复制代码

  这里，咱们确定不可能每次比较都是用深比较，去遍历全部的结构，这样带来的性能代价是巨大的，刚才咱们说到immutable.js有个特性是引用比较（hashcode），这个特性就完美契合这边的场景

2.2 如何将immutableJS集成到一个react+redux项目中

2.2.1 明确集成方案，边界界定

  首先，咱们有必要来划分一下边界，哪些数据须要使用不可变数据，哪些数据要使用原生js数据结构，哪些地方须要作互相转换

• 在redux中，全局state必须是immutable的，这点毋庸置疑是咱们使用immutable来优化redux的核心
• 组件props是经过redux的connect从state中得到的，而且引入immutableJS的另外一个目的是减小组件shouldComponentUpdate中没必要要渲染，shouldComponentUpdate中比对的是props，若是props是原生JS就失去了优化的意义
• 组件内部state若是须要提交到store的，必须是immutable，不然不强制
• view提交到action中的数据必须是immutable
• Action提交到reducer中的数据必须是immutable
• reducer中最终处理state必须是以immutable的形式处理并返回
• 与服务端ajax交互中返回的callback统一封装，第一时间转换成immutable数据

  从上面这些点能够看出，几乎整个项目都是必须使用immutable的，只有在少数与外部依赖有交互的地方使用了原生js。
  这么作的目的其实就是为了防止在大型项目中，原生js与immutable混用，致使coder本身都不清楚一个变量中存储的究竟是什么类型的数据。
  那有人可能会以为说，在一个全新项目中这样是可行的，但在一个已有的成熟项目中，要将全部的变量所有改为immutablejs，代码的改动量与侵入性很是大，风险也高。那他们会想到，将reducer中的state用fromJS()改为immutable进行state操做，而后再经过toJS()转成原生js返回出来，这样不就能够即让state变得可追溯，又不用去修改reducer之外的代码，代价很是的小。

export default function indexReducer(state, action) {
    switch (action.type) {
    case RECEIVE_MENU:
        state = immutable.fromJS(state);   //转成immutable
        state = state.merge({a:1});
        return state.toJS()    //转回原生js
    }  
}复制代码

两点问题：

1. fromJS() 和 toJS() 是深层的互转immutable对象和原生对象，性能开销大，尽可能不要使用（见下一章节作了具体的对比）
2. 组件中props和state仍是原生js，shouldComponentUpdate仍然没法作利用immutablejs的优点作深度比较

2.2.2 具体集成代码实现方法

redux-immutable

  redux中，第一步确定利用combineReducers来合并reducer并初始化state，redux自带的combineReducers只支持state是原生js形式的，因此这里咱们须要使用redux-immutable提供的combineReducers来替换原来的方法

import {combineReducers} from 'redux-immutable';
import dish from './dish';
import menu from './menu';
import cart from './cart';

const rootReducer = combineReducers({
    dish,
    menu,
    cart,
});

export default rootReducer;复制代码

  reducer中的initialState确定也须要初始化成immutable类型

const initialState = Immutable.Map({});
export default function menu(state = initialState, action) {
    switch (action.type) {
    case SET_ERROR:
        return state.set('isError', true);
    }
}复制代码

  state成为了immutable类型，那相应的页面其余文件都须要作相应的写法改变

//connect
function mapStateToProps(state) {
    return {
        menuList: state.getIn(['dish', 'list']),  //使用get或者getIn来获取state中的变量
        CartList: state.getIn(['dish', 'cartList'])
    }
}复制代码

  页面中原来的原生js变量须要改形成immutable类型，不一一列举了

服务端交互ajax封装

  前端代码使用了immutable，但服务端下发的数据仍是json，因此须要统一在ajax处作封装而且将服务端返回数据转成immutable

//伪代码
$.ajax({
    type: 'get',
    url: 'XXX',
    dataType: 'json',
    success(res){
        res = immutable.fromJS(res || {});
        callback && callback(res);
    },
    error(e) {
        e = immutable.fromJS(e || {});
        callback && callback(e);
    },
});复制代码

这样的话，页面中统一将ajax返回当作immutable类型来处理，不用担忧混淆

shouldComponentUpdate

  重中之重！以前已经介绍了不少为何要用immutable来改造shouldComponentUpdate，这里就很少说了，直接看怎么改造
shouldComponentUpdate具体怎么封装有不少种办法，咱们这里选择了封装一层component的基类，在基类中去统一处理shouldComponentUpdate，组件中直接继承基类的方式

//baseComponent.js component的基类方法

import React from 'react';
import {is} from 'immutable';

class BaseComponent extends React.Component {
    constructor(props, context, updater) {
        super(props, context, updater);
    }

    shouldComponentUpdate(nextProps, nextState) {
        const thisProps = this.props || {};
        const thisState = this.state || {};
        nextState = nextState || {};
        nextProps = nextProps || {};

        if (Object.keys(thisProps).length !== Object.keys(nextProps).length ||
            Object.keys(thisState).length !== Object.keys(nextState).length) {
            return true;
        }

        for (const key in nextProps) {
            if (!is(thisProps[key], nextProps[key])) {
                return true;
            }
        }

        for (const key in nextState) {
            if (!is(thisState[key], nextState[key])) {
                return true;
            }
        }
        return false;
    }
}

export default BaseComponent;复制代码

  组件中若是须要使用统一封装的shouldComponentUpdate，则直接继承基类

import BaseComponent from './BaseComponent';
class Menu extends BaseComponent {
    constructor() {
        super();
    }
    …………
}复制代码

  固然若是组件不想使用封装的方法，那直接在该组件中重写shouldComponentUpdate就好了

2.3 点餐H5项目优化先后对比

这边只是截了几张图举例
优化前搜索页：

优化后：

优化前购物车页：

优化后：

三. immutable.js使用过程当中的一些注意点

1.fromJS和toJS会深度转换数据，随之带来的开销较大，尽量避免使用，单层数据转换使用Map()和List()

（作了个简单的fromJS和Map性能对比，同等条件下，分别用两种方法处理1000000条数据，能够看到fromJS开销是Map的4倍）

2.js是弱类型，但Map类型的key必须是string！(看下图官网说明)

3.全部针对immutable变量的增删改必须左边有赋值，由于全部操做都不会改变原来的值，只是生成一个新的变量

//javascript
var arr = [1,2,3,4];
arr.push(5);
console.log(arr) //[1,2,3,4,5]

//immutable
var arr = immutable.fromJS([1,2,3,4])
//错误用法
arr.push(5);
console.log(arr) //[1,2,3,4]
//正确用法
arr = arr.push(5);
console.log(arr) //[1,2,3,4,5]复制代码

4.引入immutablejs后，不该该再出现对象数组拷贝的代码(以下举例)

//es6对象复制
var state = Object.assign({}, state, {
    key: value
});

//array复制
var newArr = [].concat([1,2,3])复制代码

5. 获取深层深套对象的值时不须要作每一层级的判空

//javascript
var obj = {a:1}
var res = obj.a.b.c   //error

//immutable
var immutableData=immutable.fromJS({a:1})
var res = immutableData.getIn(['a', 'b', 'c'])  //undefined复制代码

6.immutable对象直接能够转JSON.stringify(),不须要显式手动调用toJS()转原生

7. 判断对象是不是空能够直接用size

8.调试过程当中要看一个immutable变量中真实的值，能够chrome中加断点，在console中使用.toJS()方法来查看

四. 总结

  总的来讲immutable.js的出现解决了许多原生js的痛点，而且自身对性能方面作了许多的优化处理，并且immuable.js做为和react同期推出的一个产品，完美的契合了react+redux的state流处理，redux的宗旨就是单一数据流，可追溯，这两点偏偏是immutable.js的优点，天然水到渠成，何乐而不为。  固然也不是全部使用react+redux的场景都须要使用immutable.js，建议知足项目足够大，state结构足够复杂的原则，小项目能够手动处理shouldComponentUpdate，不建议使用，得不偿失。