談到Ajax,一般會想到XMLHttpRequest,但使用上並不便利,就算是標準化後的XMLHttpRequest Level 1,而且,也只是功能上的加強,開發者通常會進一步地使用程式庫封裝,像是jQuery的$.get、$.post或$.ajax。曾經有一陣子流行「你不需要jQuery」,社群裏頭也有人嚷嚷著,認為Fetch API將會取代這一切。
粗糙的XMLHttpRequest
從今日的角度來看,XMLHttpRequest確實有許多設計不足之處。
首先,一個XMLHttpRequest實例肩負著太多任務,包含了事件的註冊、請求標頭的設置、連線的開啟、資料的傳送、請求本體的設置、回應狀態的判斷、回應內容的取得等,完全不符合關切點分離(Separation of Concerns)的原則,而且,設定與呼叫順序混亂,像是開發者經常會搞不清楚,到底是要呼叫open前還是之後,設定請求標頭。
就算是2011年標準化後的XMLHttpRequest Level 1,也沒有改變XMLHttpRequest的設計。當中沒有適當地職責分離也就算了,雖然增加幾個可註冊的事件,卻依舊是採基本事件模型,而不是類似DOM Level 2事件模型那樣,可以註冊多個事件。
事實上,過去有不少程式庫,都曾經試著封裝XMLHttpRequest來解決問題。
例如,jQuery的$.get、$.post或$.ajax,$.ajax可使用選項物件(Option object)來做更多細部設定(在jQuery 3,$.get、$.post也可接受選項物件了),透過$.ajaxSetup等函式可設定預設值,這些設計非但隱藏了XMLHttpRequest的設定細節,也將一些職責從XMLHttpRequest中分離出來。
由於Ajax的處理天生就是非同步,這與開發者習慣的同步程式碼撰寫方式不同,而在非同步的作業下,處理順序也變得重要時,回呼地獄就會是個大問題。
為此jQuery提供了Deferred,而後社群中又有了Promise/A與Promise/A+規範,jQuery 3實現了Promise/A+,$.ajax可傳回Promise物件,提供了Ajax請求時更一致的模式,可以採用像是同步的程式碼來撰寫非同步應用。
HTML5的Fetch API
在2014年HTML5正式標準後不久,在Ajax這塊領域出現了許多Fetch API的介紹。
Fetch API是HTML5的一部份,Google、Mozilla在2015年於瀏覽器開始提供實作,一時之間,許多暢談Fetch API取代XMLHttpRequest的文章出現,也有不少直挑jQuery的$.ajax作為取代對象。
從設計的角度來看,Fetch API就像是過去Ajax使用上一些好實踐的集合體,可獨立地建立Headers、Request、Response實例,實現了職責分離,建立時,可使用選項物件來進行相關設定,而Fetch的工廠函式fetch也可接受選項物件,而傳回值是個Promise。
表面上,Fetch很像在XMLHttpRequest上,封裝了一層Promise,這也是它為什麼經常被拿來與$.ajax對比的原因之一,因為模式乍看之下十分類似,不過,嚴格來說,$.ajax做了比較高階的封裝。
舉例來說,$.ajax的data選項指定物件時,會自動進行序列化與請求參數編碼處理,然而,使用fetch的body選項時,必須自行建立、編碼請求參數。這是因為,在Fetch的規範(https://goo.gl/nbJKxM))前言中就清楚指出,Fetch的定位本來就是低階封裝。
Fetch另一個與XMLHttpRequest不同的地方,是Streams的支援。按照規範,回應物件的body特性會是個ReadableStream,行為上,與Streams(https://goo.gl/zWjoDv)規範中的ReadableStream相同,在伺服器的回應過程中,可以透過ReadableStream持續讀取瀏覽器已接收之內容。
雖然,過去也可以使用XMLHttpRequest的responseText,自行處理判斷、讀取想要的資料區段,然而,前者是直接處理串流資料,後者是對整個已取得之回應進行處理,本質上並不相同。
在使用Fetch的的主要考量是瀏覽器的支援度,對於不支援Fetch的瀏覽器,可以使用Fetch修補(polyfill),修補是基於XMLHttpRequest,仿造了Fetch API介面,由於XMLHttpRequest本身並沒有Streams的功能,因此在這方面的功能受限。
回頭看看Promise
由於Fetch基於Promise,在不支援Promise的瀏覽器上,除了Fetch修補之外,還要加上Promise修補(更舊的瀏覽器,像是IE8/9,還要加上ES5修補等)。而在介紹Fetch的文件中,通常都會談到的一些缺點,像是不支援逾時、進度處理等,其實,這些並不是Fetch本身的缺失,主要是來自於Promise的限制。
因為Promise/A+的規範,主要只有三個狀態,只能透過resolve、reject從未定(pending)轉移至滿足(fulfilled)或背棄(rejected)狀態。Promise實例本身也只有then、catch兩個方法,來處理對應的狀態,在不施加額外設計上,自然也就無法提供逾時、進度處理等功能。
若瞭解到某個Fetch的限制,是來自於Promise的限制,就可以試著從設計下手來解決需求。例如,可以透過Promise.race提供兩個Promise,一個是new Promise((resolve, reject) => setTimeout(() => reject('timeout'), timeout),一個來自fetch;若前者先背棄了,那麼,Promise.race傳回的Promise就算是背棄了,從而實現後續的逾時處理。
不過,這樣的設計只是模擬,fetch傳回的Promise依舊會執行,直到進入背棄或滿足狀態,而不是真的逾時而被中斷。只是Promise.race傳回的Promise會忽略其狀態罷了。簡而言之,在非同步的處理模式上,Fetch是基於Promise,因而,要能在非同步處理上活用Fetch,就建立在對Promise能有多少認識。
更進一步地,由於Fetch是基於Promise,若開發者熟悉Promise,應該也就知道,可以透過ECMAScript 6的產生器語法,採用像是同步的流程來撰寫非同步應用,進一步地,ECMAScript 7提供了async、await,而且,無論是Promise本身或者是Fetch,都可搭配async、await使用(可參考先前專欄〈從產生器到async、await〉),這會是它們未來的優勢之一。
Fetch解決了什麼?
每當有新的技術或概念出現,人們總愛說舊的東西將會死去,新的東西會取代一切。喜新厭舊吧!舊東西誕生在舊的時代,適時地解決了當時的問題,而後從中累積了不少的使用經驗,因而誕生了新的技術、概念或規範,急著預言舊東西將會逝去,並不會讓開發者看起來更為耀眼,只會讓開發者看不清楚新東西的本質罷了。
舉個舊東西好了,$.ajax可以就這麼與fetch來比較嗎?高階封裝與低階API可以直接比較嗎?
也許某些程度上,可以用Fetch解決時,無需掛個jQuery程式庫會是件好事,然而,$.ajax也許可以基於Fetch來重構,在Fetch做不到的部份,使用XMLHttpRequest來實現。XMLHttpRequest畢竟也不是完全那麼不堪,或者乾脆寫個$.fetch之類的擴充,來實現前述概念如何呢?
Fetch實際上代表的,是Ajax從XMLHttpRequest、選項物件、回呼處理、Promise,甚至往後銜接至產生器、async/await的這條發展路線中,各種實作與經驗的累積與修正,瞭解這個過程中的累積與修正,才會知道Fetch解決了什麼,又有哪些沒解決的,別急著馬上判處某些舊東西死刑,不然,過陣子可能又會急著要處死Fetch了吧!
專欄作者
熱門新聞
2024-09-29
2024-10-02
2024-10-01
2024-10-03
2024-10-04
2024-10-01
2024-10-01