前言
本文开始针对项目中总结出来的关于js基础知识的代码优化技巧进行每个细节点的分析，后续还会针对某个专题的分析。
案例说明
if针对同一关键值多条件的判断
针对key进行多条件判断，而其中的多条件可能有些可以归为一类，因为其执行的代码是相同的
//优化前
if(key === 1 || key ===3 || key===9){
//some codes here
}
//优化后
let codesOptionArr = [1,3,9]
if(codesOptionArr.includes(key)){
//some codes here
}
针对多case，分别返回或者设置不同值，代码段很简单
需要根据不同的值情况，来返回或者设定对应的值，相信很多人会说用switch来进行优化，其实用对象字面量会更好，也更方便维护和复用。比较常见的是前端常见的一些枚举数据以及固定值。
//优化前
let str =''
switch(type){
case 'name': str ='姓名'
break
case 'sex': str ='性别'
break
}
//优化后
function getTypeStr (type){
if(!type) return ''
let dict = {
name:'姓名'，
sex:'性别'
}
return dict[type] || type
}
let str = getTypeStr(type)
少写嵌套，尽早返回
缺点除了逻辑分不清楚，还会导致代码执行性能低，在执行完需要的逻辑之后不能跳出方法。所以建议针对已经符合返回的情况下 ，就返回对应的逻辑，不再进行多余的判断。
//优化前
function judgeAge(age){
let str =''
if(age && !isNaN(age) && age> 0 ){
if(age <18) {
str = '还是未成年 '
} else {
str = '符合要求'
}
} else {
str = '年龄不合法'
}
return str
}
//优化后
function judgeAge(age){
if(!age || isNaN(age) || age < 0 ){
return '年龄不合法'
}
if(age<18) return '还是未成年'
else{
return '符合要求'
}
}
方法内的返回或者对应关系具有关联关系，或者可以进行一定的代码关联设计，这里不针对对象字面量。
//优化前
let str =''
switch(number) {
case 0 : str = '没有任何收入'
break
case 1 :str='您有一枚硬币了'
break
}
return str
//优化后
let descArr = ['没有任何收入','您有一枚硬币了']
return descArr[number]
使用函数默认值和解构
也许你之前没有用过函数默认值，也没有分析过解构能带来什么优化。
// 优化前
function fn(age){
let _age = age || 0
console.log(_age)
}
// 优化后
function fn(age = 0){
console.log(age)
}
// 优化前
function fn(person){
if(person && person.name) {
console.log(pserson.name || '')
}
}
// 优化后
function fn({name}){
console.log(name || '')
}
合并条件与执行语句
在库代码中经常看到一些判断条件与执行语句、返回语句写在一起，非常简洁高效，也可读性较高。
let getArrlen= (str,arr) => {
if(!(arr instanceof(Array))) return 'arr is not arr '
return arr && arr.length
}
批量对象属性赋值
使用场景：主要是针对需要把对象的一些属性批量的赋值到另外一个对象上，然后如果你的属性很多可能要写很多赋值语句。（前提是属性名一般是相同的）
说明：可能有人会问为什么不直接用这个对象，答案也很简单，如果可以直接用，当然直接用是最好的，我自己在写接口param的时候，就会注意这些，需要传参的部分封装到一个特殊的对象里，然后进行data的绑定，这样需要的时候直接用传参对象。但这里讨论的不是这种情况。
//优化前
let data = {}
data.name = this.form.name
data.len = this.form.len
data.amount = this.form.amount
//优化版本一 ：利用对象的解构
let {name,len,amount} = this.form
//利用对象解构还可以支持属性名变更的情况
let {name,len:length,amount:money} = this.form
let data = {name,len,amount}
// 优化后
let data = this.setProps[{source:this.form,propArr:['name','len','amount']}]
//优化版本二 ：可以支持批量的导入需要赋值的，对于拷贝对象，用source属性承接，而需要赋值的属性用propArr承接
//在方法中用json的相关方法支持了简单的对象深拷贝
// 批量加载对象属性，支持传入数组[{source:sourceObj,propArr:[]}]
setProps(arr) {
if (arr.length <= 0) return {}
return arr.reduce((acc, item) => {
item.propArr.reduce((acc, prop) => {
if (typeof item.source[prop] === 'object') {
acc[prop] = JSON.parse(JSON.stringify(item.source[prop]))
} else {
acc[prop] = item.source[prop]
}
return acc
}, acc)
return acc
}, {})
}
拓展思考：像这种代码如果你的vue代码里经常写，不妨在你的mixins中混入这个方法，可以为你的页面节省大量的代码空间。
批量变量重置
在我们的代码中经常会遇到吧一些变量进行重置，这部分代码重复率很高又没有技术含量，所以我写一个工具方法进行简单的支持，代码优化。
//优化前
this.search = false
this.data = []
this.cur_page = 1
this.pageNo = 1
this.totalCount = 0
this.processType = ''
this.person = ''
this.keyword = ''
this.taskStatus = ''
this.stdate = []
this.processStatus = ''
// 优化后
this.resetVars([this.data,this.processType,this.person,this.keyword,this.taskStatus])
/**
* @author zhangbing
* @param [] arr 需要重置的数组变量
* @param {*} options 配置对象 对于这里的重置规则如果不符合需求的可以自定义option字典,然后用instanceof 判断类型（todo）
*/
resetVars(arr, options) {
if (!arr || arr.length === 0) return
let _options = {
object: {},
string: '',
number: 0,
boolean: true,
null: null,
undefined: undefined
}
_options = options ? Object.assign({}, _options, options) : _options
return arr.map(item => {
if (_options.includes(typeof item)) {
item = _options[typeof item]
} else {
// 不存在重置类型的 重置为字符串
item = ''
}
return item
})
}
拓展思考：像这种代码如果你的vue代码里经常写，不妨在你的mixins中混入这个方法，可以为你的页面节省大量的代码空间。
对象的浅拷贝与深拷贝
在js中，我们可以用等号来进行基本数据类型的赋值，而对于复杂数据类型也就是对象类型，其等号赋予的是对象地址，不能实现拷贝的目的。而我们知道的Object.assign实现的也是对象的浅拷贝。
所以一般情况下，如果你不确定的情况下，如果发现对象属性值是对象类型，需要递归拷贝。核心知识点是：typeof source[prop] === 'object' ,return Object.assign(target[prop],source[prop]),直到对象属性为基本类型.
这里所讲的不是这部分，而是利用JSON的转化方法来实现简单的对象深拷贝。当然这种方法是有弊端的，详情参考我另一篇文章利用json序列化对象的问题
let target = JSON.parse(JSON.stringify(source))
更多
以上方法只是根据个人经验和想法进行的一些可优化的思维拓展，有些可能是矫枉过正，但代码的优化道路上，从来都是要特定场景下解决特定需求的，为的还是要让使用更简单，让使用者更习惯、高效的开发，提前或者滞后的将代码进行优化重构固然都是错的，但如果一点点优化的思考和什么程度应该去做重构了不去探索就进步太慢了。
