一直以來(lái), 前端工程代碼中有著大量的對(duì)于接口返回字段值為null的處
理. 在實(shí)際項(xiàng)目中, 接口字段返回null的情況也是普遍狀況.
已然變成了一種合理形式.
這有什么問(wèn)題呢?
- 不符合接口字段的類型約定
由于前后端配合是基于接口文檔的, 每個(gè)字段都有明確的類型, 如果接口的某個(gè)字段約定是Array, 但返回的值為null, 實(shí)際上對(duì)于前端, 是類型錯(cuò)誤, null的類型是Object.
由于基于接口文檔我們預(yù)期接口返回的是Array類型,
所以, 本應(yīng)放心的使用數(shù)組的方法,
但是, 如果此時(shí)接口返回了null,
實(shí)際上是返回了Object類型,
等于違背了接口文檔的約定.
phoneNumbers.sort()
- 額外的防御性代碼, 需要手工保障
由于任何值都可能是null, 在使用是都需要防御,
隨著工程發(fā)展,這種狀況會(huì)很泛濫
ps:
事實(shí)上, 對(duì)于泛前端來(lái)說(shuō), 也需要保證代碼健壯性.
但檢查的規(guī)則, 是基于接口約定的.如果不符合接口定義會(huì)統(tǒng)一彈出統(tǒng)一報(bào)錯(cuò).而不是在業(yè)務(wù)邏輯中逐一防范.
// 如果phoneNumbers來(lái)自于接口, 且值是null , 直接就會(huì)報(bào)錯(cuò)
const phoneNumbers: number[] = []
// 此時(shí), 由于null的類型是object并不是array,
// 所以sort的方法就會(huì)在報(bào)錯(cuò).
console.log(phoneNumbers.sort())
// 這時(shí)只能先判斷再使用
if (Array.isArray(phoneNumbers) ) {
phoneNumbers.sort()
}
// 換成不嚴(yán)謹(jǐn)?shù)暮?jiǎn)單粗暴的判斷方式
phoneNumbers && phoneNumbers.sort()
那么為什么后端要返回null呢?
- 語(yǔ)言特性
java語(yǔ)言: 認(rèn)為返回默認(rèn)值會(huì)占用內(nèi)存, 比如空數(shù)組也需要占用內(nèi)存, 空字符串也要占用內(nèi)存.
- 開(kāi)發(fā)成本
對(duì)于一些后端工程, 想要加默認(rèn)值, 成本非常高, 需要逐個(gè)去加 (容我質(zhì)疑一下, 難道就沒(méi)有便捷的)
前端手動(dòng)書(shū)寫防御性代碼會(huì)帶來(lái)什么問(wèn)題?
1.難以避免的疏忽
所有依靠手動(dòng)保障的工作, 本質(zhì)上都是在對(duì)賭一個(gè)詞: “認(rèn)真”, 顯然, 智者千慮必有一失, 誰(shuí)都不能確保沒(méi)有疏忽, 如果可能使用工具代替手工才是出路.
2.難以測(cè)試, 成為線上質(zhì)量的隱患
這種防御性代碼帶來(lái)的問(wèn)題,本質(zhì)上是由數(shù)據(jù)不符合規(guī)范導(dǎo)致的, 往往開(kāi)發(fā)測(cè)試階段, 數(shù)據(jù)都是理想的, 甚至線上回歸測(cè)試時(shí)也沒(méi)問(wèn)題, 但經(jīng)常有一些線上故障是這樣的
1. 前端功能發(fā)生致命錯(cuò)誤,導(dǎo)致交互無(wú)法繼續(xù)
由于接口返回的數(shù)據(jù)沒(méi)有遵守按照協(xié)議, 導(dǎo)致的前端錯(cuò)誤.
2. 沒(méi)有報(bào)錯(cuò), 但流程異常
舉個(gè)例子: 某個(gè)枚舉值, 對(duì)應(yīng)著前端的單選框,
例如 是/否 , 起初約定0: 是, 1: 否 , 但由于某種原因數(shù)據(jù)變成了1: 是, 2: 否 ,
從交互上就出現(xiàn)了問(wèn)題且一般不會(huì)報(bào)錯(cuò).
隨著交互繼續(xù)進(jìn)行, 問(wèn)題將難以定位,
在這過(guò)程中流失的用戶訂單將會(huì)與定位、解決問(wèn)題的時(shí)間成正比, 實(shí)為不能承受之重.
現(xiàn)在, 我們面臨的問(wèn)題是什么?
- 如何保證泛前端代碼在數(shù)據(jù)交換時(shí)的健壯性.
- 前端工程的可維護(hù)性, 是否重要?
- 線上質(zhì)量與性能到底哪個(gè)重要?
以下的認(rèn)知, 期待我們能達(dá)成共識(shí):
前后端通過(guò)接口文檔(協(xié)議約定)進(jìn)行數(shù)據(jù)交換合作, 例如: 每一個(gè)字段“是否必須”, 字段類型, 枚舉, 都有唯一性的明確約定. 雙方都須遵守?cái)?shù)據(jù)交換協(xié)議, 才能保證線上質(zhì)量.
解決方案當(dāng)然也是有的, 請(qǐng)關(guān)注下一期, :
《如何不增加泛前端維護(hù)成本又能增強(qiáng)數(shù)據(jù)交換過(guò)程中泛前端代碼的健壯性》 ?
推薦給后端同學(xué)的參考閱讀:
不要再返回Null了
https://juejin.im/post/6844903683436576776
