84669 人學習
152542 人學習
20005 人學習
5487 人學習
7821 人學習
359900 人學習
3350 人學習
180660 人學習
48569 人學習
18603 人學習
40936 人學習
1549 人學習
1183 人學習
32909 人學習
什麼場景下我需要取消一個promise?
Promise 的設計就是一個狀態機,pending 到 resolve / reject 的狀態變換是單向且唯一的,沒有所謂的 cancel 狀態。 cancel 的加入會帶來更多的狀態問題,並不適合 Promise 這個模式來處理(這類場景下,RxJS 這類 FRP 的方案應該比較適合)。
cancel 會帶來什麼狀態問題呢?拿電商的退款來舉例。你買了一個東西(開始一個pending 的promise),然後東西還沒收到(還沒到resolve),你後悔了,點擊了退款(把狀態改為cancel),但這時退款流程也不能立刻生效,需要審核(cancel 後不能立刻reject),那這時候你發工資了,又不想退款了,又點了【取消退款】,這時候又是一個異步的狀態更改(把cancel 再cancel 掉) ,而【取消退款】也是異步的,你還能取消【取消退款】的操作(把cancel 在cancel 掉前再cancel 掉?)別忘了,這時候每一步狀態變化還都可以對應到resolve和reject 呢。好的同學們,接下來請畫出流程的狀態變化圖,並編碼實現這個支援 cancel 的 promise
例如頁面需要1分鐘刷新一次,但是介面特別慢,所以導致我下次發送請求的時候,上次的請求還沒有回來,在這種情況下我就想取消上次的請求。
例如按讚,取消按讚操作 如果是使用promise當你誤點讚了你想點取消讚時, 你就必須等點讚操作結束才能操作所以有了加強版的promise → observable
同時進行兩個操作(兩個Promise),其中一個完成了就把另一個取消掉,最後返回先成功的結果。
但是取消都是坑,例如多線程做取消意味著異步異常,就是操作到一半突然被完全打斷,不給一點恢復的機會(不然取消就沒意義了),所以也沒有方法進行恢復或者回滾。只有純CPU的獨立的運算任務才能安全地取消。
至於取消然後取消「取消」是不會有的,規矩進入cancel狀態(半死不活狀態)就不能切換到其他狀態就行了。
Promise 的設計就是一個狀態機,pending 到 resolve / reject 的狀態變換是單向且唯一的,沒有所謂的 cancel 狀態。 cancel 的加入會帶來更多的狀態問題,並不適合 Promise 這個模式來處理(這類場景下,RxJS 這類 FRP 的方案應該比較適合)。
cancel 會帶來什麼狀態問題呢?拿電商的退款來舉例。你買了一個東西(開始一個pending 的promise),然後東西還沒收到(還沒到resolve),你後悔了,點擊了退款(把狀態改為cancel),但這時退款流程也不能立刻生效,需要審核(cancel 後不能立刻reject),那這時候你發工資了,又不想退款了,又點了【取消退款】,這時候又是一個異步的狀態更改(把cancel 再cancel 掉) ,而【取消退款】也是異步的,你還能取消【取消退款】的操作(把cancel 在cancel 掉前再cancel 掉?)別忘了,這時候每一步狀態變化還都可以對應到resolve和reject 呢。好的同學們,接下來請畫出流程的狀態變化圖,並編碼實現這個支援 cancel 的 promise
例如頁面需要1分鐘刷新一次,但是介面特別慢,所以導致我下次發送請求的時候,上次的請求還沒有回來,在這種情況下我就想取消上次的請求。
例如按讚,取消按讚操作
如果是使用promise當你誤點讚了你想點取消讚時, 你就必須等點讚操作結束才能操作
所以有了加強版的promise → observable
同時進行兩個操作(兩個Promise),其中一個完成了就把另一個取消掉,最後返回先成功的結果。
但是取消都是坑,例如多線程做取消意味著異步異常,就是操作到一半突然被完全打斷,不給一點恢復的機會(不然取消就沒意義了),所以也沒有方法進行恢復或者回滾。只有純CPU的獨立的運算任務才能安全地取消。
至於取消然後取消「取消」是不會有的,規矩進入cancel狀態(半死不活狀態)就不能切換到其他狀態就行了。