AJAX

Asynchronous JavaScript + XML（異步JavaScript和XML）, 其本身不是一種新技術(shù)，而是一個(gè)在 2005年被Jesse James Garrett提出的新術(shù)語(yǔ)，用來(lái)描述一種使用現(xiàn)有技術(shù)集合的‘新’方法。(MDN)

AJAX 是2005年提出的一種術(shù)語(yǔ)，并不代表某個(gè)特定的技術(shù)。

其譯名 異步JavaScript和XML 描述出了核心，就是使用 JavaScript 發(fā)送異步 HTTP 請(qǐng)求，這樣就擺脫了想要和服務(wù)端交互，必須刷新頁(yè)面的痛點(diǎn)。

學(xué)習(xí) AJAX 相關(guān)內(nèi)容前，建議有一些簡(jiǎn)單的 HTTP 相關(guān)知識(shí)的儲(chǔ)備，否則很難理解其工作流程。

1. XMLHttpRequest 對(duì)象

XMLHttpRequest 對(duì)象可以提供給前端開(kāi)發(fā)人員使用 JavaScript 發(fā)起 HTTP 請(qǐng)求的能力。該對(duì)象會(huì)被簡(jiǎn)稱為 XHR 對(duì)象。

var xhr = new XMLHttpRequest();

這樣就獲得到了一個(gè) XHR 對(duì)象的實(shí)例。接下來(lái)可以使用他發(fā)起請(qǐng)求。

var xhr = new XMLHttpRequest();

xhr.onreadystatechange = function() { // 當(dāng) readyState 改變的時(shí)候
  if (xhr.readyState === 4 && xhr.status === 200) { // 判斷當(dāng)前請(qǐng)求的狀態(tài) 與 請(qǐng)求的狀態(tài)碼
    console.log(xhr.responseText); // 輸出服務(wù)端返回的內(nèi)容
  }
}
xhr.open('GET', '/', true); // 設(shè)定 GET 請(qǐng)求，請(qǐng)求的路徑是 /，并且請(qǐng)求是異步的
xhr.send(); // 發(fā)送！

onreadystatechange 是一個(gè)事件處理器屬性，每次 readyState 改變的時(shí)候都會(huì)觸發(fā)。

如果 readyState 為 4，即請(qǐng)求已經(jīng)完成，并且狀態(tài)碼是 200，表示請(qǐng)求結(jié)束并且服務(wù)端成功響應(yīng)。

響應(yīng)成功，通過(guò) responseText 獲取到服務(wù)端響應(yīng)的內(nèi)容。

通過(guò) open 方法，設(shè)置請(qǐng)求的方法、路徑等，例子中設(shè)置了 / 路徑，如果當(dāng)前站點(diǎn)的域名是 imooc.com，則請(qǐng)求地址就是 imooc.com/，拿到的數(shù)據(jù)應(yīng)該會(huì)是網(wǎng)站首頁(yè)的 HTML。

然后通過(guò) send 方法發(fā)送請(qǐng)求，發(fā)送后 readyState 會(huì)在各個(gè)階段發(fā)送改變，然后調(diào)用 onreadystatechange。

這是一個(gè) AJAX 請(qǐng)求較為基本的流程。

更多與 AJAX 相關(guān)的內(nèi)容可以參閱 AJAX Wiki，相信閱讀完會(huì)有許多收獲。

2. ActiveXObject

IE6 之前是沒(méi)有 XHR 對(duì)象的，需要使用 ActiveXObject 對(duì)象，這是 IE 特有的。

考慮到 IE6 之前版本瀏覽器的市場(chǎng)份額，個(gè)人覺(jué)得只需要做個(gè)了解，沒(méi)太大必要再去學(xué)習(xí)使用 ActiveXObject 對(duì)象。

3. 小結(jié)

現(xiàn)代網(wǎng)頁(yè)的構(gòu)成幾乎離不開(kāi) AJAX 技術(shù)，如果 JavaScript 無(wú)法發(fā)起 HTTP 請(qǐng)求，幾乎所有的現(xiàn)代網(wǎng)站都會(huì)癱瘓，變得難用。

除了 XHR 對(duì)象之外，還有 fetch API 這個(gè)后起之秀，也可以承擔(dān) XHR 對(duì)象的工作。但 fetch 還有部分缺陷，如無(wú)法監(jiān)控進(jìn)度，對(duì)狀態(tài)碼的處理邏輯不夠符合業(yè)務(wù)，所以用戶面較廣的產(chǎn)品使用一般不會(huì)選擇 fetch。