23k star超火項目，請求優化寫的一塌糊涂！我直接重構！
取消重復請求
取消重復請求是一個前端項目中很常見的網絡請求優化手段，他主要是為了防止短時間內發送了多個一模一樣的請求，導致性能的消耗~
23k star 的項目是怎么做的？
github 上有一個很火的項目，叫做 Vben-Admin，是一個非常出色的后臺管理系統模板，但是個人覺得它的取消重復請求做的一塌糊涂（下面會說理由）！！！
由于項目中源代碼比較多，我盡量簡化了代碼，給大家展示一下它是怎么去實現這個功能的
我先說一下它實現這個功能的思路：
- 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各自的后續邏輯會繼續進行
圖片
且請求只會發出一次
圖片
第一個請求報錯了咋辦？
我這個方案是以第一個請求為主的，那么，如果第一個請求失敗了，那后續的重復請求就爺跟著失敗嗎？顯然是不對的~
第一個請求失敗之后，我們必須讓后續的請求再重新走一次流程才對，就像是一切都沒發生過一樣！
只需要在后續重復請求的錯誤回調中，重新執行請求即可，這樣又能重新來過了！！！
圖片
可以看到，就算前面的失敗了，后面的照樣能自己發起請求進行自救
圖片
圖片
有完善的空間
以上只是我根據自己思路寫出的一個粗略版本，如果大家有自己其他的顧慮，可以進行修改精進！
