取消重復請求

取消重復請求是一個前端項目中很常見的網絡請求優化手段，他主要是為了防止短時間內發送了多個一模一樣的請求，導致性能的消耗~

23k star 的項目是怎么做的？

github 上有一個很火的項目，叫做 Vben-Admin，是一個非常出色的后臺管理系統模板，但是個人覺得它的取消重復請求做的一塌糊涂（下面會說理由）?。。?/p>

由于項目中源代碼比較多，我盡量簡化了代碼，給大家展示一下它是怎么去實現這個功能的

我先說一下它實現這個功能的思路：

• 1、維護一個 Map：key 是 請求的 Method + Url，value 是這個請求的取消方法
• 2、請求攔截器中：先清除掉 Map 中此請求 Method + Url 的存儲，也就是取消掉前面的重復請求，然后再進行本次請求
• 3、響應攔截器：清除掉本次請求的存儲，確保不影響下一次的判斷

簡化后的代碼如下

圖片

接著在頁面中使用

圖片

假如我點擊了三次，那么它會將我前面的兩次取消掉，只讓第三次請求成功，從而實現取消重復請求的功能~

圖片

圖片

但是這個方案缺陷真的很大，比如看下面的例子，我不止一個按鈕調用了，我有兩個按鈕去調用這個接口

圖片

我先點擊了按鈕1，再點擊按鈕2，發現它把我按鈕1的請求取消掉了，只請求了按鈕2的請求，其實這是沒錯的，但是錯就錯在，它取消了按鈕1的請求，但是連著按鈕1點擊事件接下來的代碼都中斷掉了！?。?！

圖片

可以發現，控制臺沒有打印按鈕1的結果，只打印了按鈕2的結果?。?！

圖片

這顯然是不合理的，我們取消重復請求只是為了減少網絡資源、性能的消耗，但是可不想因為這個優化，而影響了我們原本的邏輯~

其實上面的按鈕1、按鈕2，也可以類比為頁面1、頁面2，兩個頁面在短時間內發起了同一個請求，你直接去把頁面1的后續邏輯都中斷了，這不是一個好的方案?。?！

并且其實不合理的地方還有：Method + Url當做 key，確實不太合理（但是本文暫且不關注這點）

自己思考怎么做~

想了一下，不能用上述的方案來做，缺陷太大了，自己想的方式就是不取消請求了！而是直接不發請求！ 大概的思路如下：

• 1、維護一個Map：key 是 請求的 Method + Url，value 第一次請求的 Promise
• 2、第一次請求時，生成一個 Promise，存儲在 Map 中
• 3、第一次請求響應之后，修改 Promise 的狀態，并把響應數據傳給 Promise
• 4、后續的重復請求以第一次請求的 Promise 為準，確保能復用數據，且不影響各自的后續邏輯

簡化后的代碼如下：

圖片

結果如下，按鈕1、按鈕2各自的后續邏輯會繼續進行

圖片

且請求只會發出一次

圖片

第一個請求報錯了咋辦？

我這個方案是以第一個請求為主的，那么，如果第一個請求失敗了，那后續的重復請求就爺跟著失敗嗎？顯然是不對的~

第一個請求失敗之后，我們必須讓后續的請求再重新走一次流程才對，就像是一切都沒發生過一樣！

只需要在后續重復請求的錯誤回調中，重新執行請求即可，這樣又能重新來過了！！！

圖片

可以看到，就算前面的失敗了，后面的照樣能自己發起請求進行自救

圖片

圖片

有完善的空間

以上只是我根據自己思路寫出的一個粗略版本，如果大家有自己其他的顧慮，可以進行修改精進！