不要再濫用可選鏈運算子(?.)啦！

const onClick = () => {
const user = props.data?.items?.[0]?.user
if (user) {
// use user to do something
}
}


已這行程式碼為例，有個bug現象是點選按鈕沒反應，維護開發看到這塊程式碼，就會想這一串鏈式內容裏，是不是有可能有空值，所以導致了user是空值，沒走進if裏導致沒反應。 然後就繼續分析上層元件props傳輸程式碼，看data值從哪兒傳來的，看是不是哪塊程式碼導致data或items空值了。。。

其實呢？從外部傳過來的這一串內容裏不會有空值的情況，導致bug問題根本不在這兒。

const user = props.data.items[0].user


那把 ?. 都去掉呢？維護開發追蹤問題看到這行程式碼，data items 這些內容肯定不能是空值，不然console就拋錯了，但是bug現象裏並沒有拋錯， 所以只需要檢查user能不能是空值就行了，很容易就排除了很多情況。

總結就是： 給程式碼維護人員帶來了很多分析程式碼的幹擾，程式碼可讀性和維護性都很差。

2. 隱式過濾了異常

api.get(...).then(result => {
const id = result?.id
// use id to do something
})


比如有個需求，從後台api獲取數據時，需要把結果裏id內容獲取到，然後進行數據處理，從業務流程上看，這個api返回的result以及id必須有值，如果沒值的話後續的流程就會走不通。

然後後台邏輯由於寫的有問題，導致個別情況返回的 result=null，但是由於前端這裏加了 ?. ，導致頁面沒有任何反應，js不拋錯，console也沒有log，後續流程出錯了， 這時候如果想找原因就會很困難，對程式碼熟悉還行，如果不是自己寫的就只能看程式碼捋邏輯，如果是生產環境壓縮混淆了就更難排查了。

api.get(...).then(result => {
const id = result.id
// use id to do something
})


把 ?. 去掉呢？如果api返回值有問題，這裏會立即拋錯，後面的流程也就不能進行下去了，無論開發還是生產環境都能在console裏快速定位問題， 即使是壓縮混淆的也能從error看出一二，或者在一些前端監控程式裏也能監聽到。

其實這種現象跟 try catch 裏不加 throw 類似，把隱式異常錯誤完全給過濾掉了，比如下面例子：

// 這個try本意是處理api請求異常
try {
const data = getSaveData() // 這段js邏輯也在try裏，所以如果這個方法內部拋錯了，頁面上就沒任何反應，很難追蹤問題
const result = await api.post(url, data)
// result 邏輯處理
} catch (e) {
// 好點的給彈個框，打個log，甚至有的啥都不處理
}


總結就是： 把異常給隱式過濾掉了，導致不能快速定位問題。

3. 編譯後程式碼冗余

如果程式碼是ts，並且編譯目標是ES2016，編譯後程式碼會很長。可以看下 www.typescriptlang.org/play 效果。

Babel在個別stage下，編譯效果一樣。

但並不是說一點都不用，意思是盡量減少濫用，這樣使用的頻率會少很多，這種編譯程式碼沈余也會少不少。

應該怎麽用？

說了這麽多， .? 應該怎麽用呢？意思是不用嗎？當然不是不能用，這個特性對於開發肯定好處很多的，但是得合理用，不能濫用。

其實說白了就是：什麽時候需要判斷一個變量或內容非空，什麽時候不需要。首先在使用的時候得想下，問號前面的變量或內容值，有沒有可能是空值：

1. 很明顯不可能是空值，比如 React類元件裏的 this.state this.props ，不要用；

2. 自己定義的變量或內容，而且沒有賦值為空值情況，不要用；

3. 某些方法或者元件裏，參數和內容不允許是空值，那方法和元件裏就不需要判斷非空。（對於比較common的，推薦寫斷言，或者判斷空值情況throw error）

4. 後台api請求結果裏，要求result或其內部內容必須有值，那這些值就不需要判斷非空。

5. 按正常流程走，某個數據不會有空值情況，如果是空值說明前面的流程出問題了，這種情況就不需要在邏輯裏判斷非空。

const userName = data?.items?.[0]?.user?.name // 不要濫用，如果某個內容有可能是空值，則需要?.
const userName = data.items[0].user?.name // 比如data.items陣列肯定不是空陣列


const items2 = items1.filter(item => item.checked)
if (items2?.length) { } // 不需要?.


// react class component
const name = this.state?.name // 不需要?.
// react hooks
const [items, setItems] = useState([])
items?.map(...) // 如果setItems沒有賦值空值情況，則不需要?.
setItems?.([]) // 不需要?.

const item1 = obj?.item1 // 不需要?.
console.log(item1.name)


const id = obj?.id // 下面程式碼已經說明不能是空值了，不需要?.
const name = obj.name


if (obj?.item1?.item2) {
const item2 = obj?.item1?.item2 // 不需要?.
const name = obj?.item1?.item2?.name // 不需要?.
}


const id = obj?.item?.id // 不需要?.
api.get(id).then(...) // 這個api如果id是空值，則api會拋錯


當然，寫程式碼時還得多想一下內容是否可能是空值， 會一定程度的影響開發效率，也一定有開發會覺得很煩，不理解，無腦寫 ?. 多容易啊 ，但是我從另外兩個角度分析下：

1. 我覺得一個合格的開發應該對自己的程式碼邏輯很熟悉，應該有責任知道哪些值可能是空值，哪些不可能是空值（並不是說所有，也有大部份了），否則就是對自己的程式碼了解很少，覺得程式碼能跑就行，程式碼品質自然就低。

2. 想想在這個新特性出來之前大家是怎麽寫的，會對每個變量和內容都加 if非空判斷 或者用 邏輯與(&&) 嗎？不會吧。