前端工程化

webpack工程化

提高构建速度

• webpack4
• 缩小搜索extention范围，强制后缀
• dll

减少大小

• 分析资源图
• 按需加载

做了哪些优化

debounc和throttle

尽量采用受控组件

redux-thunk和redux-saga选型问题?

老大考虑到团队成员学习的曲线，最终选择thunk
为了更方便团队人员使用，封装直接的thunk，和cobineReducer

• 为什么要封装conbineReducer？

1、项目分为四大块，服务治理，资源治理，诊断调试，分析管理
几十个组件，不可能将所有的状态卸载一个reducer里面来管理
不利于维护

然后因为封装了组件thunk所以要用自己封装的combineReducer来更新state

paas抽离的公共组件

• 表单action的，增加，删除，修改（图标来表示）
• cluster展示 {name}
• 节流优化，搜索过滤组件（debounce)
• 优化过的AutoComplete

<data={data} searchData={() => this.handleSearchData(filterData)}>

仿saga

• Ali-thunk中间件

effects = modelx.getEffects()
const myThunk = (store) => (next) => (action) => {
    let typeArr = action.type.split('/')
    let isEffect = [typeArr][1].includes('@')
    let name = typeArr[0]
    let method = typeArr[1]
    if(isEffect){
        return  effects[name][method](store.dispatch,store.getState(),action.payload)
    }
    next(action) //走原生dipatch(action)
}


// createStore中的原生dispatch方法
dispatch(action){
    newState = reducers(state,action)
}

• modexl.js

• 深拷贝

function deepClone(obj){
    return Object.assign({},obj)
}

2、组件做到粒度细分，而且高内聚低耦合

• paas

1 产品化不足，体验不够好

手机主要体验差的点

• workflow

定义的一个状态机，多个状态，一个状态到另一个状态
YAML文件

利用的是远程调用（RMI)
workflow由于调用频率和场景特殊的原因，持续保持心跳必然带来资源浪费
简单来说就是，将所有请求在一个连接中完成，维持一个长连接