Fetch - 錯(cuò)誤方法
在 JavaScript 中fetch非常棒。
但是，您的代碼中可能會(huì)散布著這樣的內(nèi)容：
const res = await fetch('/user')
const user = await res.json()這段代碼雖然簡單易用，但存在許多問題。
你可以說“哦，是的，錯(cuò)誤處理”，然后像這樣重寫它：
try {
const res = await fetch('/user')
const user = await res.json()
} catch (err) {
// 錯(cuò)誤處理
}當(dāng)然，這是一個(gè)改進(jìn)，但仍然存在問題。
在這里，我們假設(shè) user 實(shí)際上是一個(gè)用戶對(duì)象……但這假設(shè)我們得到了 200 響應(yīng)。
但 fetch 不會(huì)針對(duì)非 200 狀態(tài)拋出錯(cuò)誤，因此您實(shí)際上可能收到 400（錯(cuò)誤請(qǐng)求）、401（未授權(quán)）、404（未找到）、500（內(nèi)部服務(wù)器錯(cuò)誤）或各種其他問題 .
一種更安全但更丑陋的方式
因此，我們可以進(jìn)行另一個(gè)更新：
try {
const res = await fetch('/user')
if (!res.ok) {
switch (res.status) {
case 400: /* Handle */ break
case 401: /* Handle */ break
case 404: /* Handle */ break
case 500: /* Handle */ break
}
}
// User是這次的用戶
const user = await res.json()
} catch (err) {
// 錯(cuò)誤處理
}現(xiàn)在，我們終于很好地使用了 fetch。 但這可能有點(diǎn)笨拙，因?yàn)槊看味急仨氂涀?，而且你必須希望你團(tuán)隊(duì)中的每個(gè)人每次都能處理這些情況。
它在控制流方面也不是最優(yōu)雅的。 在可讀性方面，我個(gè)人更喜歡本文開頭的有問題的代碼。 它讀起來很干凈——獲取用戶，解析為 json，用用戶對(duì)象做事。
但在這種格式中，我們獲取用戶、處理一堆錯(cuò)誤情況、解析 json、處理其他錯(cuò)誤情況等。這有點(diǎn)不和諧，尤其是此時(shí)我們?cè)跇I(yè)務(wù)邏輯之上和之下都有錯(cuò)誤處理，而不是 集中在一個(gè)地方。
一種不那么丑陋的方式
如果請(qǐng)求有問題，一個(gè)更優(yōu)雅的解決方案可能是拋出異常，而不是在多個(gè)地方處理錯(cuò)誤：
try {
const res = await fetch('/user')
if (!res.ok) {
throw new Error('Bad fetch response')
}
const user = await res.json()
} catch (err) {
// 錯(cuò)誤處理
}但是我們還有最后一個(gè)問題——當(dāng)需要處理錯(cuò)誤時(shí)，我們丟失了很多有用的上下文。 我們實(shí)際上無法訪問 catch 塊中的 res，因此在處理錯(cuò)誤時(shí)我們實(shí)際上并不知道響應(yīng)的狀態(tài)代碼或主體是什么。
這將使我們很難知道要采取的最佳措施，并給我們留下非常無用的日志。
此處改進(jìn)的解決方案可能是創(chuàng)建您自己的自定義錯(cuò)誤類，您可以在其中轉(zhuǎn)發(fā)響應(yīng)詳細(xì)信息：
class ResponseError extends Error {
constructor(message, res) {
super(message)
this.response = res
}
}
try {
const res = await fetch('/user')
if (!res.ok) {
throw new ResponseError('Bad fetch response', res)
}
const user = await res.json()
} catch (err) {
// 處理錯(cuò)誤，可以完全訪問狀態(tài)和正文
switch (err.response.status) {
case 400: /* Handle */ break
case 401: /* Handle */ break
case 404: /* Handle */ break
case 500: /* Handle */ break
}
}現(xiàn)在，當(dāng)我們保留狀態(tài)代碼時(shí)，我們可以更智能地處理錯(cuò)誤。
例如，我們可以在 500 上提醒用戶我們遇到了問題，并可能重試或聯(lián)系我們的支持。
或者如果狀態(tài)為 401，他們當(dāng)前未授權(quán)，可能需要重新登錄等。
創(chuàng)建包裝器
我有一個(gè)關(guān)于我們最新最好的解決方案，最后一個(gè)問題——它仍需要開發(fā)人員每次都編寫一些像樣的樣板文件。 在整個(gè)項(xiàng)目范圍內(nèi)進(jìn)行更改，或強(qiáng)制使用此結(jié)構(gòu)，仍然是一個(gè)挑戰(zhàn)。
這就是我們可以根據(jù)需要包裝 fetch 來處理事情的地方：
class ResponseError extends Error {
constructor(message, res) {
this.response = res
}
}
export async function myFetch(...options) {
const res = await fetch(...options)
if (!res.ok) {
throw new ResponseError('Bad fetch response', res)
}
return res
}然后我們可以按如下方式使用它：
try {
const res = await myFetch('/user')
const user = await res.json()
} catch (err) {
// Handle issues via error.response.*
}在我們的最后一個(gè)例子中，最好確保我們有一個(gè)統(tǒng)一的方式來處理錯(cuò)誤。 這可能包括給用戶的警報(bào)、日志記錄等。
開源解決方案
探索很有趣，但重要的是要記住，您不必總是為事物創(chuàng)建自己的包裝器。 以下是一些流行且可能值得使用的現(xiàn)有選項(xiàng)，包括一些小于 1kb 的選項(xiàng)：
Axios
axios 是一個(gè)非常流行的 JS 取數(shù)據(jù)選項(xiàng)，它自動(dòng)為我們處理了上面的幾個(gè)場景。
try {
const { data } = await axios.get('/user')
} catch (err) {
// 根據(jù)error.response.*進(jìn)行錯(cuò)誤處理
}我對(duì) Axios 的唯一批評(píng)是它對(duì)于一個(gè)簡單的數(shù)據(jù)獲取包裝器來說大得驚人。 因此，如果 大小是您的首要任務(wù)（我認(rèn)為這通常應(yīng)該是為了保持您的性能一流），您可能需要查看以下兩個(gè)選項(xiàng)之一：
Redaxios
如果你喜歡 Axios，但不喜歡它會(huì)給你的包增加 11kb大小，Redaxios 是一個(gè)很好的選擇，它使用與 Axios 相同的 API，但不到 1kb。
import axios from 'redaxios'
// 像往常一樣使用
Wretch
一個(gè)較新的選項(xiàng)是 Wretch，它是 Fetch 的一個(gè)非常薄的包裝器，就像 Redaxios 一樣。 Wretch 的獨(dú)特之處在于它在很大程度上仍然感覺像fetch，但為您提供了處理常見狀態(tài)的有用方法，這些狀態(tài)可以很好地鏈接在一起：
const user = await wretch("/user")
.get()
// 以更易于閱讀的方式處理錯(cuò)誤情況
.notFound(error { /* ... */ })
.unauthorized(error { /* ... */ })
.error(418, error { /* ... */ })
.res(response /* ... */)
.catch(error { /* 其他錯(cuò)誤*/ })也不要忘記安全地寫入數(shù)據(jù)
最后但同樣重要的是，我們不要忘記直接使用 fetch 在通過 POST、PUT 或 PATCH 發(fā)送數(shù)據(jù)時(shí)可能會(huì)遇到常見的陷阱
你能發(fā)現(xiàn)這段代碼中的錯(cuò)誤嗎？
// 這里至少有一個(gè)錯(cuò)誤，你能發(fā)現(xiàn)嗎？
const res = await fetch('/user', {
method: 'POST',
body: { name: 'Steve Sewell', company: 'Builder.io' }
})
至少有一個(gè)，但可能是兩個(gè)。
首先，如果我們發(fā)送 JSON，body 屬性必須是一個(gè) JSON 序列化的字符串：
const res = await fetch('/user', {
method: 'POST',
// ? 我們必須對(duì)這個(gè)主體進(jìn)行 JSON 序列化
body: JSON.stringify({ name: 'Steve Sewell', company: 'Builder.io' })
})這很容易忘記，但如果我們使用 TypeScript，這至少可以自動(dòng)為我們提示。
TypeScript 不會(huì)為我們捕獲的另一個(gè)錯(cuò)誤是我們沒有在此處指定 Content-Type 標(biāo)頭。 許多后端要求您指定它，否則它們將無法正確處理正文。
const res = await fetch('/user', {
headers: {
// ? 如果我們發(fā)送序列化的 JSON，我們應(yīng)該設(shè)置 Content-Type：
'Content-Type': 'application/json'
},
method: 'POST',
body: JSON.stringify({ name: 'Steve Sewell', company: 'Builder.io' })
})現(xiàn)在，我們有了一個(gè)相對(duì)健壯和安全的解決方案。
（可選）向我們的包裝器添加自動(dòng) JSON 支持
我們也可以決定在包裝器中為這些常見情況添加一些安全措施。 例如使用以下代碼：
const isPlainObject = value value?.constructor === Object
export async function myFetch(...options) {
let initOptions = options[1]
// 如果我們?yōu)?fetch 指定了一個(gè) RequestInit
if (initOptions?.body) {
// 如果我們傳遞了一個(gè) body 屬性并且它是一個(gè)普通對(duì)象或數(shù)組
if (Array.isArray(initOptions.body) || isPlainObject(initOptions.body)) {
//創(chuàng)建一個(gè)新的選項(xiàng)對(duì)象序列化主體并確保我們有一個(gè)內(nèi)容類型的header
initOptions = {
...initOptions,
body: JSON.stringify(initOptions.body),
headers: {
'Content-Type': 'application/json',
...initOptions.headers
}
}
}
}
const res = await fetch(...initOptions)
if (!res.ok) {
throw new ResponseError('Bad fetch response', res)
}
return res
}
現(xiàn)在我們可以像這樣使用我們的包裝器：
const res = await myFetch('/user', {
method: 'POST',
body: { name: 'Steve Sewell', company: 'Builder.io' }
})簡單安全。 我喜歡。
開源解決方案
雖然定義我們自己的抽象既有趣又有趣，但讓我們可以指出幾個(gè)流行的開源項(xiàng)目如何自動(dòng)為我們處理這些情況：
Axios/Redaxios
對(duì)于 Axios 和 Redaxios，類似于我們帶有原始提取的原始“有缺陷”代碼的代碼實(shí)際上按預(yù)期工作：
const res = await axios.post('/user', {
name: 'Steve Sewell', company: 'Builder.io'
})Wretch
同樣，對(duì)于 Wretch，最基本的示例也可以按預(yù)期工作：
const res = await wretch('/user').post({
name: 'Steve Sewell', company: 'Builder.io'
})（可選）使我們的包裝器類型安全
最后但同樣重要的是，如果你想圍繞 fetch 實(shí)現(xiàn)自己的包裝器，如果你正在使用它，我們至少要確保它是類型安全的 TypeScript。
這是我們的最終代碼，包括類型定義：
const isPlainObject = (value: unknown) => value?.constructor === Object
class ResponseError extends Error {
response: Response
constructor(message: string, res: Response) {
super(message)
this.response = res
}
}
export async function myFetch(input: RequestInfo | URL, init?: RequestInit): Promise<Response> {
let initOptions = init
if (initOptions?.body) {
if (Array.isArray(initOptions.body) || isPlainObject(initOptions.body)) {
initOptions = {
...initOptions,
body: JSON.stringify(initOptions.body),
headers: {
"Content-Type": "application/json",
...initOptions.headers,
},
}
}
}
const res = await fetch(input, initOptions)
if (!res.ok) {
throw new ResponseError("Bad response", res)
}
return res
}
最后一個(gè)陷阱
當(dāng)使用我們新型類型安全提取包裝器時(shí)，您將遇到最后一個(gè)問題。 在typescript的 catch 塊中，默認(rèn)錯(cuò)誤是任何類型（any）
try {
const res = await myFetch
} catch (err) {
// 哦，錯(cuò)誤是“任何（any）”類型
if (err.respons.status === 500) ...
}
你可以說，哦！ 我只輸入錯(cuò)誤：
try {
const res = await myFetch
} catch (err: ResponseError) {
// TS error 1196: Catch clause variable type annotation must be 'any' or 'unknown' if specified
}呃，沒錯(cuò)，我們不能在 TypeScript 中輸入錯(cuò)誤。 那是因?yàn)閺募夹g(shù)上講，你可以在任何地方將任何東西放入 TypeScript。 以下是所有有效的 JavaScript/TypeScript，理論上可以存在于任何 try 塊中
throw null
throw { hello: 'world' }
throw 123
// ...
更不用說 fetch 本身可能會(huì)拋出它自己的錯(cuò)誤，這不是 ResponseError，例如網(wǎng)絡(luò)錯(cuò)誤，例如沒有可用的連接。
我們也可能不小心在我們的 fetch 包裝器中有一個(gè)合法的錯(cuò)誤，它會(huì)拋出其他錯(cuò)誤，比如 TypeError
因此，此包裝器的最終、干凈且類型安全的用法類似于：
try {
const res = await myFetch
const user = await res.body()
} catch (err: unknown) {
if (err instanceof ResponseError) {
switch (err.response.status) { ... }
} else {
throw new Error('An unknown error occured when fetching the user', {
cause: err
})
}在這里，我們可以使用 instanceof 檢查 err 是否是 ResponseError 實(shí)例，并在錯(cuò)誤響應(yīng)的條件塊中獲得完整的類型安全。
然后，如果發(fā)生任何意外錯(cuò)誤，我們也可以重新拋出錯(cuò)誤，并使用 JavaScript 中新的 cause 屬性轉(zhuǎn)發(fā)原始錯(cuò)誤詳細(xì)信息，以便更好地調(diào)試。
可重用的錯(cuò)誤處理
最后，最好不要總是為每個(gè) HTTP 調(diào)用的每個(gè)可能的錯(cuò)誤狀態(tài)都定制一個(gè)switch。
將我們的錯(cuò)誤處理封裝到一個(gè)可重用的函數(shù)中會(huì)更好，我們可以在處理任何我們知道需要特殊邏輯的一次性情況后將其用作回退，因?yàn)樵撜{(diào)用是該調(diào)用所獨(dú)有的。
例如，我們可能有一種常用的方式，希望用“哎呀，對(duì)不起，請(qǐng)聯(lián)系技術(shù)支持”消息提醒用戶出現(xiàn)500問題，或者對(duì)于401問題，如果沒有更具體的方式來處理這個(gè)特定請(qǐng)求的狀態(tài)，就會(huì)使用“請(qǐng)?jiān)俅蔚卿洝毕ⅰ?/span>
在實(shí)踐中，它可以是這樣的:
try {
const res = await myFetch('/user')
const user = await res.body()
} catch (err) {
if (err instanceof ResponseError) {
if (err.response.status === 404) {
// 這個(gè)調(diào)用的特殊邏輯，我們想要處理這個(gè)狀態(tài)，比如在404上，我們似乎沒有這個(gè)用戶
return
}
}
// ?? 處理任何其他我們不需要特殊邏輯的事情，只需要我們的默認(rèn)處理
handleError(err)
return
}我們可以這樣實(shí)現(xiàn):
export function handleError(err: unkown) {
// 保存到我們選擇的日志服務(wù)
saveToALoggingService(err);
if (err instanceof ResponseError) {
switch (err.response.status) {
case 401:
// 提示用戶重新登錄
showUnauthorizedDialog()
break;
case 500:
// 向用戶顯示一個(gè)對(duì)話框，我們有一個(gè)錯(cuò)誤，并再試一次，如果還不行，請(qǐng)聯(lián)系技術(shù)支持
showErrorDialog()
break;
default:
// Show
throw new Error('Unhandled fetch response', { cause: err })
}
}
throw new Error('Unknown fetch error', { cause: err })
}使用Wretch
這是我認(rèn)為Wretch的亮點(diǎn)之一，因?yàn)樯厦娴拇a可能類似于:
try {
const res = await wretch.get('/user')
.notFound(() { /* 特殊的未找到邏輯 */ })
const user = await res.body()
} catch (err) {
// 使用默認(rèn)處理程序捕獲其他所有內(nèi)容
handleError(err);
return;
}使用Axios/Redaxios
使用Axios或Redaxios，看起來與我們最初的示例類似
try {
const { data: user } = await axios.get('/user')
} catch (err) {
if (axios.isAxiosError(err)) {
if (err.response.status === 404) {
// 未找到的邏輯
return
}
}
//使用默認(rèn)處理程序捕獲其他所有內(nèi)容
handleError(err)
return
}結(jié)論
這樣就完成了!
如果不清楚，我個(gè)人建議使用現(xiàn)成的包裝器來實(shí)現(xiàn)fetch，因?yàn)樗鼈兛赡芊浅Ｐ?1-2kb)，通常有更多的文檔、測試和社區(qū)，而且已經(jīng)被其他人證明和驗(yàn)證了是一個(gè)有效的解決方案。
但這一切都說了，無論你是選擇手動(dòng)使用fetch，編寫自己的包裝器，還是使用開源包裝器——為了你的用戶和你的團(tuán)隊(duì)，請(qǐng)確保正確地獲取你的數(shù)據(jù)。
