傳統 Ajax 已死，Fetch 永生（轉載）
此為三輪轉載
傳統 Ajax 已死，Fetch 永生
原諒我做一次標題黨，Ajax 不會死，傳統 Ajax 指的是 XMLHttpRequest（XHR），未來現在已被 Fetch 替代。
最近把阿里一個千萬級 PV 的資料產品全部由 jQuery 的 $.ajax 遷移到 Fetch，上線一個多月以來執行非常穩定。結果證明，對於 IE8+ 以上瀏覽器，在生產環境使用 Fetch 是可行的。
由於 Fetch API 是基於 Promise 設計，有必要先學習一下 Promise，推薦閱讀 MDN Promise 教程。舊瀏覽器不支援 Promise，需要使用 polyfill es6-promise
本文不是 Fetch API 科普貼，其實是講非同步處理和 Promise 的。Fetch API 很簡單，看文件很快就學會了。推薦 MDN Fetch 教程 和 萬能的WHATWG Fetch 規範
Why Fetch
XMLHttpRequest 是一個設計粗糙的 API，不符合關注分離（Separation of Concerns）的原則，配置和呼叫方式非常混亂，而且基於事件的非同步模型寫起來也沒有現代的 Promise，generator/yield，async/await 友好。
Fetch 的出現就是為了解決 XHR 的問題，拿例子說明：
使用 XHR 傳送一個 json 請求一般是這樣：
var xhr = new XMLHttpRequest();
xhr.open('GET', url);
xhr.responseType = 'json';
xhr.onload = function() {
console.log(xhr.response);
};
xhr.onerror = function() {
console.log("Oops, error");
};
xhr.send();
使用 Fetch 後，頓時看起來好一點
fetch(url).then(function(response) { return response.json(); }).then(function(data) { console.log(data); }).catch(function(e) { console.log("Oops, error"); });
使用 ES6 的 箭頭函式 後：
fetch(url).then(response => response.json())
.then(data => console.log(data))
.catch(e => console.log("Oops, error", e))
現在看起來好很多了，但這種 Promise 的寫法還是有 Callback 的影子，而且 promise 使用 catch 方法來進行錯誤處理的方式有點奇怪。不用急，下面使用 async/await 來做最終優化：
注：async/await 是非常新的 API，屬於 ES7，目前尚在 Stage 1(提議) 階段，這是它的完整規範。使用 Babel 開啟 runtime 模式後可以把 async/await 無痛編譯成 ES5 程式碼。也可以直接使用 regenerator 來編譯到 ES5。
try {
let response = await fetch(url);
let data = response.json();
console.log(data);
} catch(e) {
console.log("Oops, error", e);
}
// 注：這段程式碼如果想執行，外面需要包一個 async function
duang~~ 的一聲，使用 await 後，寫非同步程式碼就像寫同步程式碼一樣爽。await 後面可以跟 Promise 物件，表示等待 Promise resolve() 才會繼續向下執行，如果 Promise 被 reject() 或丟擲異常則會被外面的 try...catch 捕獲。
await/async，generator/yield 可以粗略地認為是 Promise 的語法糖（其實功能上也有增強）。因此它們可以和 Fetch 完美搭配使用。這也是使用標準 Promise 一大好處。最近也把專案中使用第三方 Promise 庫的程式碼全部轉成標準 Promise，為以後全面使用 async/await 做準備。
另外，Fetch 也很適合做現在流行的同構應用，有人基於 Fetch 的語法，在 Node 端基於 http 庫實現了 node-fetch，又有人封裝了用於同構應用的 isomorphic-fetch。
注：同構(isomorphic/universal)就是使前後端運行同一套程式碼的意思，後端一般是指 NodeJS 環境。
總結一下，Fetch 優點主要有：
- 語法簡潔，更加語義化
- 基於標準 Promise 實現，支援 async/await
Fetch 啟用方法
下面是重點↓↓↓
先看一下 Fetch 原生支援率：
瀏覽器對 Fetch 支援率
原生支援率並不高，幸運的是，引入下面這些 polyfill 後可以完美支援 IE8+ ：
- 由於 IE8 是 ES3，需要引入 ES5 的 polyfill: es5-shim, es5-sham
- 引入 Promise 的 polyfill: es6-promise
- 引入 fetch 的 polyfill: fetch-ie8
- 可選：如果你還使用了 jsonp，引入 fetch-jsonp
- 可選：開啟 Babel 的 runtime 模式，現在就使用 async/await
Fetch polyfill 的基本原理是探測是否存在 window.fetch 方法，如果沒有則用 XHR 實現。這也是 github/fetch 的做法，但是有些瀏覽器（Chrome 45）原生支援 Fetch，但響應中有中文時會亂碼，老外又不太關心這種問題，所以我自己才封裝了 fetch-detector 和 fetch-ie8 只在瀏覽器穩定支援 Fetch 情況下才使用原生 Fetch。這些庫現在每天有幾千萬個請求都在使用，絕對靠譜！
終於，引用了這一堆 polyfill 後，可以愉快地使用 Fetch 了。但要小心，下面有坑：
Fetch 常見坑
- Fetch 請求預設是不帶 cookie 的，需要設定
fetch(url, {credentials: 'include'}) - 伺服器返回 400，500 錯誤碼時並不會 reject，只有網路錯誤這些導致請求不能完成時，fetch 才會被 reject。
竟然沒有提到 IE，這實在太不科學了，現在來詳細說下 IE
IE 使用策略
所有版本的 IE 均不支援原生 Fetch，fetch-ie8 會自動使用 XHR 做 polyfill。但在跨域時有個問題需要處理。
IE8, 9 的 XHR 不支援 CORS 跨域，雖然提供 XDomainRequest，但這個東西就是玩具，不支援傳 Cookie！如果介面需要許可權驗證，還是乖乖地使用 jsonp 吧，推薦使用 fetch-jsonp。如果有問題直接提 issue，我會第一時間解決。
標準 Promise 的不足
由於 Fetch 是典型的非同步場景，所以大部分遇到的問題不是 Fetch 的，其實是 Promise 的。ES6 的 Promise 是基於 Promises/A+ 標準，為了保持簡單簡潔，只提供極簡的幾個 API。如果你用過一些牛 X 的非同步庫，如 jQuery(不要笑) 、Q.js 或者 RSVP.js，可能會感覺 Promise 功能太少了。
沒有 Deferred
Deferred 可以在建立 Promise 時可以減少一層巢狀，還有就是跨方法使用時很方便。
ECMAScript 11 年就有過 Deferred 提案，但後來沒被接受。其實用 Promise 不到十行程式碼就能實現 Deferred：es6-deferred。現在有了 async/await，generator/yield 後，deferred 就沒有使用價值了。
沒有獲取狀態方法：isRejected，isResolved
標準 Promise 沒有提供獲取當前狀態 rejected 或者 resolved 的方法。只允許外部傳入成功或失敗後的回撥。我認為這其實是優點，這是一種宣告式的介面，更簡單。
缺少其它一些方法：always，progress，finally
always 可以通過在 then 和 catch 裡重複呼叫方法實現。finally 也類似。progress 這種進度通知的功能還沒有用過，暫不知道如何替代。
最後
Fetch 替換 XHR 只是時間問題，現在看到國外很多新的庫都預設使用了 Fetch。
最後再做一個大膽預測：由於 async/await 這類新非同步語法的出現，第三方的 Promise 類庫會逐漸被標準 Promise 替代，使用 polyfill 是現在比較明智的做法。
作者：Cam
連結：https://www.jianshu.com/p/THLARe
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。