本文開始針對項目中總結出來的關於js基礎知識的代碼優化技巧進行每一個細節點的分析,後續還會針對某個專題的分析。前端
針對key進行多條件判斷,而其中的多條件可能有些能夠歸爲一類,由於其執行的代碼是相同的vue
//優化前
if(key === 1 || key ===3 || key===9){
//some codes here
}
//優化後
let codesOptionArr = [1,3,9]
if(codesOptionArr.includes(key)){
//some codes here
}
複製代碼
須要根據不一樣的值狀況,來返回或者設定對應的值,相信不少人會說用switch來進行優化,其實用對象字面量會更好,也更方便維護和複用。比較常見的是前端常見的一些枚舉數據以及固定值。json
//優化前
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]
複製代碼
也許你以前沒有用過函數默認值,也沒有分析過解構能帶來什麼優化。bash
// 優化前
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中混入這個方法,能夠爲你的頁面節省大量的代碼空間。優化
在咱們的代碼中常常會遇到吧一些變量進行重置,這部分代碼重複率很高又沒有技術含量,因此我寫一個工具方法進行簡單的支持,代碼優化。ui
//優化前
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))
複製代碼
以上方法只是根據我的經驗和想法進行的一些可優化的思惟拓展,有些多是矯枉過正,但代碼的優化道路上,歷來都是要特定場景下解決特定需求的,爲的仍是要讓使用更簡單,讓使用者更習慣、高效的開發,提早或者滯後的將代碼進行優化重構當然都是錯的,但若是一點點優化的思考和什麼程度應該去作重構了不去探索就進步太慢了。