日记3(immutable.js)

240 阅读2分钟

immutable.js

  • 资料

    github, 手册
  • 背景

    今天在项目中看到了自己曾在reducer中有这样一部分代码:

    import { fromJS } from 'immutable';
    import { PENDING, FULFILLED, REJECTED } from 'redux-promise-middleware';
    import * as at from './actionTypes';

    const INITIAL_STATE = fromJS({
      list: [],
      pagination: {
        pageSize: 20,
        total: 0,
        page: 1,
      },
      loading: false,
    });

    export default (state = INITIAL_STATE, action) => {
      switch (action.type) {
        case `${at.GET_USE_RESULT}_${FULFILLED}`:
            return state
                .update('list', () => fromJS(action.payload.data.list))
                .update('pagination', val =>
                    fromJS(
                        Object.assign({}, val.toJS(), {
                            total: action.payload.data.total,
                        })
                    )
                )
                .set('loading', false)
        default:
            return state;

上面对代码的问题就在于自己更新pagination.total值的方式。尽管语法没什么问题但是看着总觉得非常别扭,于是翻了一下手册找到了setIn来代替,改进了更新total的方式如下:

    case `${at.GET_USE_RESULT}_${FULFILLED}`:资料
        return state
            .update('list', () => fromJS(action.payload.data.list))
            .updateIn(['pagination', 'total'], action.payload.data.total)
            .set('loading', false)
  • 问题--为什么要用immutable.js

    react项目中为什么要使用Immutable.js,它能实现的功能我明明用原生的js都能实现啊!恩,理由就是它性能更好!但是为什么呢,以前的自己也没有去具体的查过,就想当然的觉得性能更好所以就使用它。今天补了相关知识了解到主要原因有以下2点:

    1. JS的深浅复制
       JS的深浅复制讲起来得很久很久了,半壶水的自己今天也补了一下这方面的知识。
       深复制一般是开辟一块新的内存地址,将原对象的各个属性逐个递归复制出去。
       浅复制,新旧对象则是指向同一块内存地址。
    2. React DIff算法
       这方面更是半壶水了,了解过能侃侃而谈但似乎没什么用[逃]~~
  • 学习
    浏览了一遍手册,避免以后再遇到类似问题。
    尽量优先使用immutable已有方法,毕竟更加安全可靠方面

工作小插曲

昨天的工作小插曲后,今天项目组开了一个AAR(after action review)会,总结了一下昨天的事故。一方面是怎么发生的如何避免以后发生。另一方面则是事故发生后我们怎么处理!昨天我们项目组知道发生事故的那一刻起,先是笑,然后是查原因和责任人,大概过了接近20分钟才在公司的大群里面发了声音!”公关“得不够及时,没有分清事情发生后的轻重缓急!现在想想也是,事故发生后第一反应应该是怎么解决造成的后果承担责任,然后再查明原因避免再犯!


明日计划

  • node.js错误捕获与处理(半路杀出的immutable阻断了计划)