理解為什麼 Fetch 需要等兩次✨-js教程-PHP中文網

Understanding Why Fetch Requires await Twice✨

JavaScript 的 fetch API 廣泛用於發出 HTTP 請求，但理解為什麼它有時需要兩個 wait 語句可能有點棘手。如果您以前使用過 fetch，您可能遇到過以下程式碼：

const response = await fetch('https://api.example.com/data');
const data = await response.json();

登入後複製

讓我們分解一下並理解為什麼這種模式是必要的。？

fetch API 旨在非同步處理網路請求，但其行為分為兩個主要階段：

取得回應 ?
- 當你呼叫 fetch 時，它會回傳一個 Promise，一旦網路請求完成，該 Promise 就會解析為 Response 物件。
- 此步驟不處理回應正文；它僅確保請求成功且標頭可用。
閱讀回應正文 ?
- Response 物件具有 .json()、.text() 和 .blob() 等方法來讀取實際內容。
- 這些方法也傳回 Promises，因為讀取正文是異步的。這是有效處理大型負載而不阻塞主執行緒所必需的。

當您寫 const response = wait fetch(url); 時，會發生以下情況：

已發送網路請求： ?
- 瀏覽器向指定的URL發起HTTP請求。
- 這涉及解析網域名稱、建立 TCP 連線以及發送 HTTP 標頭和正文（對於 POST 請求）。
收到回應元資料： ?
- 一旦伺服器回應狀態行（例如，HTTP/1.1 200 OK）和標頭，提取呼叫就會解析。在此刻：
  - 狀態（例如 200、404 或 500）和狀態文字（例如「確定」或「未找到」）可用。
  - 回應標頭（例如 Content-Type、Content-Length）以及伺服器發送的任何自訂標頭都是可存取的。
已建立回應物件： ?️
- 瀏覽器建構一個 Response 對象，其中包含有關響應的元資料。這包括：
  - 標頭：可透過response.headers訪問，它允許您檢查特定標頭，例如內容類型或授權。
  - 正文： 此時，正文尚未完全讀取或解析 - 它仍然是可讀流。

例如，如果伺服器回傳：

   HTTP/1.1 200 OK
   Content-Type: application/json
   Content-Length: 123

   {"message": "Hello, world!"}

登入後複製

回應物件將包含：

當您編寫 const data = wait response.json(); 時，會發生以下步驟：

身體流動閱讀： ?
- 回應正文（仍為原始形式）作為流讀取。根據您使用的方法，原始資料會進行相應的處理：
  - .json()：將流解析為 JSON 並傳回 JavaScript 物件。
  - .text()：將流讀取為純文字字串。
  - .blob()：將流讀取為二進位大物件。
解析與解析： ?
- json() 方法將原始資料（例如，{"message": "Hello, world!"}）解析為可用的 JavaScript 物件（例如，{ message: "Hello, world!" }）。
- 此解析過程是非同步的，因為它涉及處理潛在的大數據。
承諾決議： ✅
- response.json() 傳回的 Promise 解析為解析後的數據，然後可以在您的應用程式中使用該數據。

這是您需要等待兩次的原因：

如果您跳過任一等待，您可能會出現意想不到的行為：

以下是使用 fetch 時正確處理錯誤的方法：

const response = await fetch('https://api.example.com/data');
const data = await response.json();

登入後複製

不處理錯誤：
- fetch 不會拋出 404 或 500 等 HTTP 錯誤。您必須手動檢查 response.ok 或 response.status。
跳過第二個等待：
- 忘記等待 .json() 可能會導致您使用 Promise 而不是實際資料時發生錯誤。
fetch 與舊版 API 之間的混淆：
- 從 XMLHttpRequest 等舊 API 過渡的開發人員可能會期望同步行為，但 fetch 完全基於 Promise。