SAP 电商云 Spartacus UI 修改 Delivery Mode 触发的三个 HTTP 请求
LoaderState:
loading 狀態在 true 和 false 之間的切換,通過 loader
.reducer.ts 里的 reducer 函數進行。每次通過 store.dispatch 往 store 里投遞新的 action 時,都會觸發該 reducer 的執行。
添加上打印日志:
設置 delivery mode 的用戶點擊,觸發一個 put 請求,兩個 get 請求:
4秒的 proces 從 loading 到 loaded
2秒的 Multi Cart Data 從 loading 到 loaded
3秒的 Checkout Details 從 loading 到 loaded
為什么會打印兩次?
從時間軸能看出是串行關系:
HTTP PUT 先執行完,然后才是 cart 數據的讀取。
完整的時間軸:
逐一解答。
process
當我點擊 radio input 之后,通過了下圖 245 行 filter projection 的考驗之后,進入 251 行 store.dispatch 操作。因此,如果當前 cart 不 stable,并且 checkout Service 處于 loading 狀態時, 不會執行到 251 行:
當前 isLoading 為 false,只有這樣才能通過 245 行的 filter 操作:
checkout Store 是構造函數依賴注入的 store API.
所以 process 就是 setDeliveryMode 的 entity 類型。
上圖的 dispatch 操作,居然會觸發到我應用代碼里的 tap hook. 這是期望中的行為,因為 deliveryModeSetInProcess 通過 combineLatest 返回,從語義上說,checkoutService 的 loading 狀態,和 Checkout Delivery Service 的 getSetDeliveryModeProcess 方法,只要有任意發生變化,都會觸發 deliveryModeSetInProcess$ 的 subscribe 執行。
這個常量好面熟:
tap 這里為什么是 true?
因為這里是 true:
會調用兩次,打印第二次 tap hook。如果不用 combineLatest,會不會還是有這個行為?
標志著 delivery mode set 完成:
tap hook 再次觸發:
這次就看不到明顯的是通過 application code 來觸發的痕跡:
并不是通過下圖這段代碼觸發的:
緊接著,開始 load cart 數據了:Multi Cart Data
從調用棧能看出,準備加載 multi cart :
我現在希望通過代碼調試,找到具體是哪一行拋出的 action:
從調用棧里沒找到也沒關系,通過源代碼搜索也很好找:
[Cart] Load Cart
從 callstack 真的沒有找到:
setDeliveryModeSuccess 之后,立即重新 LoadCart:
cart 數據加載完畢:
checkout detail 又開始加載了:
這個 checkout detail,會影響我們這個 in process$:
48 行的 isLoading 又變為 true了,這會導致 UI option 重新處于 disabled 狀態。
等 checkout details 執行成功后,UI 重新處于可編輯狀態:
[Checkout] Checkout Details
Checkout 觸發代碼:
為什么設置 delivery mode,會觸發 59行代碼?
當 cart 的 stable 狀態發生變化時,就會觸發59行的回調,可以理解成依賴。
通過這段代碼驗證:
輸出:
combinedLatest 輸入參數有任意一個 Observable 發生了變化,則 tap 都會觸發。
現在的問題是,從我點了 input radio 之后,“Premium Delivery”:
sequential:
更多Jerry的原創文章,盡在:“汪子熙”:
總結
以上是生活随笔為你收集整理的SAP 电商云 Spartacus UI 修改 Delivery Mode 触发的三个 HTTP 请求的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 关于 TypeScript 联合类型 u
- 下一篇: FGO弗朗西斯·德雷克好用