immutable.js
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点:
- JS的深浅复制
JS的深浅复制讲起来得很久很久了,半壶水的自己今天也补了一下这方面的知识。 深复制一般是开辟一块新的内存地址,将原对象的各个属性逐个递归复制出去。 浅复制,新旧对象则是指向同一块内存地址。
- React DIff算法
这方面更是半壶水了,了解过能侃侃而谈但似乎没什么用[逃]~~
- JS的深浅复制
- 学习
浏览了一遍手册,避免以后再遇到类似问题。 尽量优先使用immutable已有方法,毕竟更加安全可靠方面
工作小插曲
继昨天的工作小插曲后,今天项目组开了一个AAR(after action review)会,总结了一下昨天的事故。一方面是怎么发生的如何避免以后发生。另一方面则是事故发生后我们怎么处理!昨天我们项目组知道发生事故的那一刻起,先是笑,然后是查原因和责任人,大概过了接近20分钟才在公司的大群里面发了声音!”公关“得不够及时,没有分清事情发生后的轻重缓急!现在想想也是,事故发生后第一反应应该是怎么解决造成的后果承担责任,然后再查明原因避免再犯!
明日计划
- node.js错误捕获与处理(半路杀出的immutable阻断了计划)