資訊專欄INFORMATION COLUMN
摘要：背景有時我們能在開發(fā)者工具的里觀察到應(yīng)用會發(fā)出某些狀態(tài)為取消的請求。如下圖第五個請求。之前有一種似是而非的說法極短時間內(nèi)發(fā)送兩個請求，則第一個會自動被掉。前一個請求的還處于的時候。就讀的代碼和觀察到的現(xiàn)象，在上發(fā)起或者的時候。
背景
有時我們能在Chrome開發(fā)者工具的Network tab里觀察到SAP UI5應(yīng)用會發(fā)出某些狀態(tài)為"取消"的OData請求。如下圖第五個請求。
之前有一種似是而非的說法:極短時間內(nèi)發(fā)送兩個OData請求，則第一個會自動被cancel掉。
這個說法從字面上看，有兩點值得推敲:
1. cancel掉，被誰cancel掉？UI5框架還是Chrome？
2. “極短”，多短算極短？
我用代碼在for循環(huán)里一共發(fā)10個OData請求：
無論是同步還是異步，都沒有任何的請求被cancel。
10個同步請求：
10個異步請求：
就算發(fā)100個request都不會有一個request被cancel:
驗證結(jié)果，之前的說法“極短時間內(nèi)發(fā)送兩個OData request，前一個會自動被cancel掉”是錯誤的。
那再回到本文第一張圖觀察到的cancel的場景, 原因究竟是什么？
觀察產(chǎn)生了被取消的OData請求的應(yīng)用代碼，觀察到第523行有這個refresh操作：
在這個方法的第601行，bChangeDetected變量為true導(dǎo)致abortPendingRequest的調(diào)用。
abortPendingRequest的注釋已經(jīng)很清楚地說明問題了。
什么情況下會導(dǎo)致AbortPendingRequest? 直接使用Chrome開發(fā)者工具的全文搜索得到答案：OData model的三個API: filter, sort, refresh
下面是我的同事Li Ben的進一步補充。
關(guān)于這個現(xiàn)象發(fā)生的原因和條件的問題1. 在哪里可以看到這個cancel現(xiàn)象?
在我們的live search功能上，如果輸入較快或者正常速度輸入，會看到前面很多輸入請求都會被cancel掉:
如果輸入較慢則不會:
真的是快慢的原因嗎？
仔細觀察network發(fā)現(xiàn)，真正的原因是當(dāng)上一次的network還處于pending狀態(tài)的時候，繼續(xù)輸入發(fā)起的請求就會cancel掉上一次的請求:
繼續(xù)深究， 這是在哪里做到的？
在SAP UI5的OData框架里面有這樣的實現(xiàn):
在ODataModel.js中維護了一個http request的pending list，將已經(jīng)發(fā)送但是還沒有收到響應(yīng)的request對象都緩存在這個列表中:
每次發(fā)起OData請求的時候都會調(diào)用ODataModel的_request()方法，這個方法會把當(dāng)前的request加到pending list中，并且通過一個wrap method包裝回調(diào)函數(shù)，確保在響應(yīng)返回的時候首先把緩存的request對象從pending list中拿掉:
每次在OData Model上發(fā)起filter, sort, refresh操作的時候，都會檢查是否存在pending的request對象，如果存在未完成的請求，abort掉它:
回答上面的問題，在什么情況下會發(fā)生這種現(xiàn)象?
1. 同一個ODataModel的instance上發(fā)出的連續(xù)請求，因為pending list是緩存在this級別上面的。
2. 前一個Http請求的network還處于pending status的時候。
3. 就讀ODataModel的代碼和觀察到的現(xiàn)象，在ODataModel上發(fā)起filter, sort或者refresh的時候。
為什么在OData的request對象上發(fā)起abort調(diào)用就可以取消底層的network call?
簡單的說，UI5里面的OData Request對象是底層的Ajax Request對象XmlHttpRequest的一個代理，在ODataModel的_submit方法中:
具體實現(xiàn)是UI5中利用了一個第三方的庫datajs，datajs最終會調(diào)用瀏覽器的底層http對象XMLHttpRequest:
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/44549.html
摘要：背景有時我們能在開發(fā)者工具的里觀察到應(yīng)用會發(fā)出某些狀態(tài)為取消的請求。如下圖第五個請求。之前有一種似是而非的說法極短時間內(nèi)發(fā)送兩個請求，則第一個會自動被掉。前一個請求的還處于的時候。就讀的代碼和觀察到的現(xiàn)象，在上發(fā)起或者的時候。 背景 有時我們能在Chrome開發(fā)者工具的Network tab里觀察到SAP UI5應(yīng)用會發(fā)出某些狀態(tài)為取消的OData請求。如下圖第五個請求。 之前有一種似...
摘要：背景有時我們能在開發(fā)者工具的里觀察到應(yīng)用會發(fā)出某些狀態(tài)為取消的請求。如下圖第五個請求。之前有一種似是而非的說法極短時間內(nèi)發(fā)送兩個請求，則第一個會自動被掉。前一個請求的還處于的時候。就讀的代碼和觀察到的現(xiàn)象，在上發(fā)起或者的時候。 背景 有時我們能在Chrome開發(fā)者工具的Network tab里觀察到SAP UI5應(yīng)用會發(fā)出某些狀態(tài)為取消的OData請求。如下圖第五個請求。 之前有一種似...
摘要：背景有時我們能在開發(fā)者工具的里觀察到應(yīng)用會發(fā)出某些狀態(tài)為取消的請求。如下圖第五個請求。之前有一種似是而非的說法極短時間內(nèi)發(fā)送兩個請求，則第一個會自動被掉。前一個請求的還處于的時候。就讀的代碼和觀察到的現(xiàn)象，在上發(fā)起或者的時候。 背景 有時我們能在Chrome開發(fā)者工具的Network tab里觀察到SAP UI5應(yīng)用會發(fā)出某些狀態(tài)為取消的OData請求。如下圖第五個請求。 之前有一種似...
摘要：達摩院的科學(xué)家們最近在用識別謠言的研究上，有了一些小突破。有始有終，皆大歡喜達摩院所研發(fā)的謠言粉碎機，在剛剛結(jié)束的全球語義測試中，創(chuàng)造了假新聞識別準確率的新紀錄，達到了前所未有的。謠言粉碎機技術(shù)的背后，是一次史無前例的信任重建。 showImg(https://segmentfault.com/img/remote/1460000018343265); 生命不可能從謊言中開出燦爛的鮮花...
閱讀 2241·2021-11-18 10:02
閱讀 3495·2021-11-15 11:36
閱讀 1122·2019-08-30 14:03
閱讀 738·2019-08-30 11:08
閱讀 2767·2019-08-29 13:20
閱讀 3293·2019-08-29 12:34
閱讀 1380·2019-08-28 18:30
閱讀 1646·2019-08-26 13:34
