5月iOS設備好評榜：iPhone 14僅排第43？
來到新的一月，安兔兔的各個榜單又重新匯總了數據，像安卓陣營的榜單都有著比較大的變動，不過iOS由于設備的更新換代并沒有那么快，所以相對來說變化并不大，特別是iOS好評榜，老款設
取消重復請求是一個前端項目中很常見的網絡請求優化手段，他主要是為了防止短時間內發送了多個一模一樣的請求，導致性能的消耗~
github 上有一個很火的項目，叫做 Vben-Admin，是一個非常出色的后臺管理系統模板，但是個人覺得它的取消重復請求做的一塌糊涂（下面會說理由）！！！
由于項目中源代碼比較多，我盡量簡化了代碼，給大家展示一下它是怎么去實現這個功能的
我先說一下它實現這個功能的思路：
簡化后的代碼如下
圖片
接著在頁面中使用
圖片
假如我點擊了三次，那么它會將我前面的兩次取消掉，只讓第三次請求成功，從而實現取消重復請求的功能~
圖片
圖片
但是這個方案缺陷真的很大，比如看下面的例子，我不止一個按鈕調用了，我有兩個按鈕去調用這個接口
圖片
我先點擊了按鈕1，再點擊按鈕2，發現它把我按鈕1的請求取消掉了，只請求了按鈕2的請求，其實這是沒錯的，但是錯就錯在，它取消了按鈕1的請求，但是連著按鈕1點擊事件接下來的代碼都中斷掉了！！！！
圖片
可以發現，控制臺沒有打印按鈕1的結果，只打印了按鈕2的結果！！！
圖片
這顯然是不合理的，我們取消重復請求只是為了減少網絡資源、性能的消耗，但是可不想因為這個優化，而影響了我們原本的邏輯~
其實上面的按鈕1、按鈕2，也可以類比為頁面1、頁面2，兩個頁面在短時間內發起了同一個請求，你直接去把頁面1的后續邏輯都中斷了，這不是一個好的方案！！！
并且其實不合理的地方還有：Method + Url當做 key，確實不太合理（但是本文暫且不關注這點）
想了一下，不能用上述的方案來做，缺陷太大了，自己想的方式就是不取消請求了！而是直接不發請求！ 大概的思路如下：
簡化后的代碼如下：
圖片
結果如下，按鈕1、按鈕2各自的后續邏輯會繼續進行
圖片
且請求只會發出一次
圖片
我這個方案是以第一個請求為主的，那么，如果第一個請求失敗了，那后續的重復請求就爺跟著失敗嗎？顯然是不對的~
第一個請求失敗之后，我們必須讓后續的請求再重新走一次流程才對，就像是一切都沒發生過一樣！
只需要在后續重復請求的錯誤回調中，重新執行請求即可，這樣又能重新來過了！！！
圖片
可以看到，就算前面的失敗了，后面的照樣能自己發起請求進行自救
圖片
圖片
以上只是我根據自己思路寫出的一個粗略版本，如果大家有自己其他的顧慮，可以進行修改精進！
本文鏈接：http://www.tebozhan.com/showinfo-26-93864-0.html23k star超火項目，請求優化寫的一塌糊涂！我直接重構！
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號