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