js實(shí)現axios限制請求隊列

目錄

背景是：

在實(shí)際開(kāi)發(fā)中，可能會(huì )遇到網(wǎng)絡(luò )問(wèn)題或者查詢(xún)量比較大的情況，上一個(gè)請求還沒(méi)有完成，用戶(hù)就發(fā)起了下一個(gè)請求。

會(huì )造成什么情況呢？

但是同一個(gè)請求多次發(fā)送到服務(wù)器，無(wú)疑是對服務(wù)器的一種壓力，所以需要在已經(jīng)優(yōu)化服務(wù)器過(guò)查詢(xún)速度后，以及用戶(hù)網(wǎng)絡(luò )情況比較差的條件下，在前端進(jìn)行請求限制。

axios 自帶的cancelToken可以幫我們實(shí)現這個(gè)需求，并且提供給了我們一個(gè)現成的api axios.CancelToken ，這是一個(gè)返回值是帶有請求信息的回調函數，我們可以在需要cancel的時(shí)候去執行這個(gè)回調函數。具體實(shí)現如下：

const service = axios.create({});
const penddingMap = new Map();
const addPendding = (config) => {
 config.cancelToken = config.cancelToken || new axios.CancelToken(cancel => {
  if(!penddingMap.has(config.url)){
   penddingMap.set(config.url,cancel);
  }
 })
}

const removePendding = (config) => {
 if(penddingMap.has(config.url)){
  let cancel = penddingMap.get(config.url);
    cancel(config.url);
    penddingMap.delete(config.url)
 }
}

本地維護一個(gè)Map來(lái)存儲每個(gè)請求信息， addPendding 中每次會(huì )去先判斷是否有cancelToken，如果有就不用重新創(chuàng )建一個(gè)cancelToken。 removePendding 中判斷請求信息是否在Map中，如果該請求存在于Map中，則執行cancel函數，并刪除Map中的該請求。

攔截器中的具體應用：

service.interceptors.request.use(config => {
 removePending(config) // 如果存在Map中先cancel該請求
  addPendding(config)  // 添加該請求到Map中
  return config
})

service.interceptors.response.use(response => {
 ``` // some code
  return response.data
}，error => {
 // 捕獲cancel請求并拋出
  if(error instanceof Cancel){
    error.message = '上一請求尚未結束，稍等~';
    Message.error(error.message);
    return Promise.reject(error.response) 
  // 這里拋出需要注意，在請求時(shí)調用try-catch進(jìn)行捕獲
  })
)

這里攔截成功后，就可以限制住大流量的多次請求。

這里只是一個(gè)例子，也可以通過(guò)判斷按鈕邏輯來(lái)控制用戶(hù)是否發(fā)起請求。

到此這篇關(guān)于js實(shí)現axios限制請求隊列的文章就介紹到這了,更多相關(guān)js axios限制請求隊列內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！