天天都成長一點系列(一)

天天都成長一點系列(一)

今天同事諮詢了我這樣一個問題
有倆個下拉選項 有關聯性的 意思就是a下拉不選 b下拉也選不了 而後提交的時候 若是a、b都選了 就向後臺傳a_b 若是b沒選 就向後臺傳a 都沒選 就向後臺傳null 並附上代碼 讓我認爲對錯或者有沒有更優的寫法
代碼以下
let a = 'a'
let b = 'b'
const id = b ? \${a}\_${b}` : a ? a : null`
首先 這樣寫是沒問題的 可是可讀性就狠差 甚至我以爲都不如用if else來的更直觀 因而我加以改進
代碼以下
const id = (a && b) ? \${a}\_${b}` : (a || null)`
實話 我我的認爲我這樣寫可讀性能稍微好一丟丟 勉強算改進
可是 上述倆種寫法都面臨着一個嚴重的問題 就是可擴展性都太差 譬如又多了一個下拉選擇 那麼 對於上述的倆種寫法都是致命的打擊 因此 有沒有更優的寫法呢 答案固然是有
代碼以下
let c = 'c'
const id = \[a, b, c\].reduce((id, item, index) \=> {

if (item) {
    id = id ? \`${id}\_${item}\` : item
}
return  id

`}, '') || null'
這是我暫時能想到的最優的寫法 優勢在於 就算再增長下拉選擇 譬如c 也不須要改動原有的代碼 還有 就是若是下拉選項變成非關聯性的 也是不須要改動代碼的
比較氣的是 同事並無採納 緣由是 拼個id須要寫個方法？ 其實 我以爲真的有必要 正所謂前人栽樹後人乘涼 否則真的要被後人罵的 因此說該勤快的地方仍是要勤快的 須要多考慮的地方也是應該多考慮的 這是對後人的負責 也是對本身的負責 固然還能自我提升 何樂而不爲！！！(這代碼怎麼粘成這個鬼樣子)