Axios 是一個基于 Promise 的 HTTP 客戶端，每周 npm 下載量超過 4000 萬。 如果回到10年前，promise式的請求工具是一個偉大的創(chuàng)新。 它解決了繁瑣的請求問題。

但隨著時間的推移，Axios 在開發(fā)效率和性能上開始落后。 特別是現(xiàn)在面對越來越復(fù)雜的需求，我們需要的是更加創(chuàng)新和領(lǐng)先的請求工具，而promise式的請求工具只能稱之為傳統(tǒng)。 

接下來，我會揭露Axios在某些方面的不足，并推薦一個比Axios更現(xiàn)代、更創(chuàng)新的請求工具，也就是上面的輕量級請求策略庫。

一、Promise式請求工具（Axios）的弱點

1.1 與React、Vue等框架分離

現(xiàn)在前端幾乎離不開React、Vue等前端UI框架。 axios無法深度綁定這些框架的狀態(tài)，需要開發(fā)者自行維護，導(dǎo)致開發(fā)效率低下。

1.2 性能方面沒有

現(xiàn)在是2023年，應(yīng)用已經(jīng)比10年前的應(yīng)用復(fù)雜了好幾個數(shù)量級，對請求的要求也越來越高，以保證頁面的性能要求。 axios在這方面什么都不做，比如頻繁重復(fù)請求，同時發(fā)起多個相同的請求等。

1.3 體積臃腫

根據(jù)bundle phobia，axios在壓縮狀態(tài)下的體積是11+kb，見下圖

1.4 響應(yīng)數(shù)據(jù)的Ts類型定義混亂

在使用axios的時候，你可能經(jīng)常會這樣寫：

const inst = axios.create({
  baseURL: 'https://example.com/'
})


inst.interceptors.response.use(response => {
  if (response.status === 200) {
    return response.data
  }
  throw new Error(response.status)
})


interface Resp {
  id: number
}
inst.get('/xxx').then(result => {
  data.data
})

不知道Axios是故意的還是忽略了。 在上面發(fā)起的GET請求中，響應(yīng)數(shù)據(jù)結(jié)果的類型一直是axios.AxiosResponse，但是我們在響應(yīng)攔截器中返回了response.data。 這導(dǎo)致陷入混亂的響應(yīng)數(shù)據(jù)類型。

2、Alova是如何解決以上問題的？

2.1 與UI框架深度集成，自動管理請求相關(guān)數(shù)據(jù)

假設(shè)我們需要發(fā)起一個基本的數(shù)據(jù)獲取請求，以Vue為例，直接對比代碼。

// axios

// alova

在axios中，你需要創(chuàng)建相應(yīng)的請求狀態(tài)并自行維護，而Alova為你接手了這項工作。

2.2 開箱即用的高性能特性

傳統(tǒng)的 Promise 風(fēng)格的請求工具主要定位是通過 Promise 簡化請求，提升性能可能是他們考慮最少的。 

但是，請求策略庫Alova強調(diào)了這一點。 在 Alova 中，默認(rèn)情況下啟用內(nèi)存。 緩存和請求共享，這兩個可以極大的提升請求性能，提升用戶體驗，減輕服務(wù)器壓力，我們一一來看。

內(nèi)存緩存

內(nèi)存模式是在響應(yīng)請求后，將響應(yīng)數(shù)據(jù)保存在本地內(nèi)存中。 下次再發(fā)起同樣的請求時，將使用緩存的數(shù)據(jù)，而不是再次發(fā)送請求。

想象一下，當(dāng)你在實現(xiàn)一個列表頁面時，點擊列表項就可以進入詳情頁面查看數(shù)據(jù)。 你會認(rèn)為用戶可能會經(jīng)常點擊查看列表中的詳細信息。 在詳情數(shù)據(jù)沒有變化的情況下，每次進入詳情頁請求一次，每次都需要用戶等待加載，太浪費了。 在Alova，你可以默認(rèn)享受這樣的待遇。

要求分享

您可能遇到過這種情況。 當(dāng)一個請求發(fā)送但沒有得到響應(yīng)時，再次發(fā)起同一個請求，造成請求浪費，或者重復(fù)提交的問題，比如下面三種場景：

• 當(dāng)一個組件被創(chuàng)建時，它會獲得初始化數(shù)據(jù)。 當(dāng)一個頁面同時渲染多個組件時，會同時發(fā)送多個相同的請求。
• 提交按鈕未禁用且用戶多次單擊提交按鈕。
• 預(yù)加載完成前進入預(yù)加載頁面時，會多次發(fā)起同一個請求。

共享請求就是用來解決這些問題的。 它是通過多路復(fù)用請求來實現(xiàn)的。 由于這種情況不能直觀展示，就不展示了。 有興趣的小伙伴可以自行體驗。

重量輕

壓縮狀態(tài)下的Alova只有4kb+，只有Axios的30%+，看下面截圖

2.3 更直觀的響應(yīng)數(shù)據(jù)TS類型

在 axios 中，要定義響應(yīng)數(shù)據(jù)的類型是令人困惑的。 如果你是 Typescript 的重度用戶，alova 可以為你提供完整的字體體驗。 當(dāng)你在請求處定義響應(yīng)數(shù)據(jù)的類型時，你可以在多個地方享受它，它會讓你感覺很清晰，我們來看看。

interface Resp {
  id: number
}
const pageData = createAlova({ baseURL: 'http://xxx' }).Get('/index');
const {
  data,  
  loading, error, onSuccess, send
} = useRequest(pageData);
onSuccess(event => {
  console.log(event.data);
});


const handleClick = async () => {
  const data = await send();
}

至此，相對于傳統(tǒng)的Promise風(fēng)格的請求庫，你可能對alova的強大有了初步的了解。

3. Alova的其他特點

3.1 類似axios的API設(shè)計，更易上手熟悉

Alova 的請求信息結(jié)構(gòu)與 Axios 幾乎相同。 讓我們比較一下他們的 GET 和 POST 請求。

// axios
axios.get('/index', {
  headers: {
    'Content-Type': 'application/json;charset=UTF-8'
  },
  params: {
    userId: 1
  }
});


// alova
const todoListGetter = alovaInstance.Get('/index', {
  headers: {
    'Content-Type': 'application/json;charset=UTF-8'
  },
  params: {
    userId: 1
  }
});

// axios
axios.post('/login', {
  username: 'xxx',
  password: 'ppp'
}, {
  headers: {
    'Content-Type': 'application/json;charset=UTF-8'
  },
  params: {
    userId: 1
  }
});


// alova
const loginPoster = alovaInstance.Post('/login', {
  username: 'xxx',
  password: 'ppp'
}, {
  headers: {
    'Content-Type': 'application/json;charset=UTF-8'
  },
  params: {
    userId: 1
  }
});

3.2 高性能尋呼請求策略

自動維護分頁相關(guān)數(shù)據(jù)和狀態(tài)，提供通用的分頁數(shù)據(jù)操作能力。 據(jù)官方介紹，可提升列表頁流暢度300%，編碼難度降低50%。 

下面是官方提供的例子，感興趣的同學(xué)可以去看看。

3.3 無感數(shù)據(jù)交互的請求策略

據(jù)我了解，它使用以下技術(shù)：

• 持久化請求隊列，保證請求的安全性和序列化
• 請求重試策略機制，保證請求的順利完成
• 虛擬響應(yīng)數(shù)據(jù)（一個創(chuàng)新概念）用作無響應(yīng)數(shù)據(jù)的占位符，以便在響應(yīng)后可以將其定位并替換為實際數(shù)據(jù)。

3.4 數(shù)據(jù)預(yù)取

數(shù)據(jù)是通過拉取數(shù)據(jù)進行預(yù)加載，緩存在本地。 這部分?jǐn)?shù)據(jù)用到的時候，可以打緩存，直接顯示數(shù)據(jù)。 這種方式也大大提高了用戶體驗。

新聞名稱：我放棄Axios，改用Alova
當(dāng)前地址：http://uogjgqi.cn/article/cojsceh.html