# Current Checkout Design
 
When we toggle delivery method via radio input, once clicked, there’re three sequential HTTP request sent to backend:
當我們點選 shipping method 時， 會有三個`序列`的 HTTP 請求傳送往後臺。

![](https://img-blog.csdnimg.cn/img_convert/0665b9a364e2d9f600f3ded93e3b47e0.png)

這個序列請求的行為，從 Chrome 開發者工具時序圖裡清晰可見。

# Request1: HTTP PUT to set delivery mode
 
url: https://20.83.184.244:9002/occ/v2/electronics-spa/users/current/carts/00002735/deliverymode?deliveryModeId=standard-gross&lang=en&curr=USD
 
這個 HTTP put 請求用於修改訂單的交貨模式。

this request is triggered in delivery-mode.component.ts, method changeMode.

![](https://img-blog.csdnimg.cn/img_convert/2c30b3cb7217c87d6b8b5bffc86c7acf.png)

模式修改的觸發，從 service 類的 setDeliveryMode 開始。

The call will be delegated to service class below:

![](https://img-blog.csdnimg.cn/img_convert/74f47d2cbdc45a61b732de6e448b4ad6.png)

# Request2: HTTP get to load [Multi Cart] Multi Cart Data
 
https://20.83.184.244:9002/occ/v2/electronics-spa/users/current/carts/00002735?fields=DEFAULT,potentialProductPromotions,appliedProductPromotions,potentialOrderPromotions,appliedOrderPromotions,entries(totalPrice(formattedValue),product(images(FULL),stock(FULL)),basePrice(formattedValue,value),updateable),totalPrice(formattedValue),totalItems,totalPriceWithTax(formattedValue),totalDiscounts(value,formattedValue),subTotal(formattedValue),deliveryItemsQuantity,deliveryCost(formattedValue),totalTax(formattedValue,%20value),pickupItemsQuantity,net,appliedVouchers,productDiscounts(formattedValue),user,saveTime,name,description&lang=en&curr=USD
 
This HTTP GET request is triggered in code: checkout.effect.ts, after previous HTTP PUT request is finished successfully:

當 HTTP PUT 執行完畢後，重新載入 Cart：

![](https://img-blog.csdnimg.cn/img_convert/8f7c5dacd27f6d26343e504c7f19e25b.png)

# Request 3: HTTP get to load [Checkout] Checkout Details
https://20.83.184.244:9002/occ/v2/electronics-spa/users/current/carts/00002735?fields=deliveryAddress(FULL),deliveryMode,paymentInfo(FULL)&lang=en&curr=USD
trigged in checkout-details.service.ts, line 59.
When 2nd HTTP request is finished, cart is stable again, so trigger loadCheckoutDetails method.

Cart 成功載入(stable)之後，載入 checkout Detail 資料：
![](https://img-blog.csdnimg.cn/img_convert/298ef83099c5ed697fb942d81d39fe98.png)

# 當前設計的缺陷

The problem of current design
 
Let’s have a look at checkout-delivery.service.ts.
When a user toggles the delivery mode radio input, it DOES NOT mean the HTTP GET request will be sent to backend automatically.

The semantic meaning of line 244 below is: HTTP PUT request could NOT be fired, unless both prerequisites are fulfilled:
1.       Cart is stable
2.       Check out loading is finished.

透過 Actions 執行 setDeliveryMode 的行為是受保護的，僅當 Cart stable 並且 isLoading 為 false 時才執行：
![](https://img-blog.csdnimg.cn/img_convert/a938e7ef16faf469a2bd77bf2def71b8.png)

The happy path:
15:42:31 355 user toggles with standard delivery mode
15:42:31 360 since cart is stable, checkout loading is false, so fire HTTP PUT request
15:43:31 361 HTTP PUT request is fired
In happy path, HTTP PUT request is fired almost immediately after user clicks radio input.

![](https://img-blog.csdnimg.cn/img_convert/08815366e33170d457692ff0efa579f9.png)

在 3G 慢速網路下測試會出現問題。

Test under slow 3G network, we have trouble now.
 
## 復現場景

1.       Move to delivery mode page. Standard Delivery radio input is selected.
2.       Click “Premium Delivery”. Radio input is disabled – works as expected.
3.       Radio input is enabled – works as expected
4.       Toggle back to “Standard Delivery”.
Expected behavior: radio input is disabled again.
Current behavior: radio input is NOT disabled.

![](https://img-blog.csdnimg.cn/img_convert/19d028867caa1da57d1dddfa2af84c6f.png)

The following is time sequence after standard delivery input is clicked again ( test step 4 described above )
1.       15:45:57 User clicks “Standard delivery”
2.       15:45:57 isStable is false, since at this time, the cart load HTTP GET request for previously selected premium Delivery mode is still on the way.
3.       15:45:59 the 2nd HTTP GET request has finished.  
4.       15:45:59 The 3rd HTTP GET request ( Load checkout detail )for previously selected premium Delivery mode is fired.
5.       15:45:59 two seconds passed after user clicks “Standard delivery”, but HTTP PUT request still could not be fired, since isStable = false
6.       XHR log
7.       Cart is stable now, isLoading = true, since 3rd HTTP GET request is still on the way.
8.       3rd HTTP GET request for previously selected premium Delivery mode has finished.
9.       15:46: 02 Cart is stable, isLoading = false. OK, now it’s time to fire HTTP PUT request for “standard delivery”.
Totally 5 seconds passed after user clicks “standard delivery”, unfortunately.

![](https://img-blog.csdnimg.cn/img_convert/8b227f50824c3e7c70b837d889e7657b.png)
Currently, we disable radio input by deliveryModeSetInProcoess$. However, its value could only be changed when there’s a HTTP PUT request sent to 
backend.

deliveryModeSetInProcoess$ 的值只有 HTTP put 操作傳送之後，才有機會被修改。

```typescript
deliveryModeSetInProcess$ = this.checkoutDeliveryService
    .getSetDeliveryModeProcess()
    .pipe(map((state) => state.loading));
```

而 HTTP put 有兩個外部依賴：

As explained above, HTTP PUT request sending has two external dependencies:
1.       Cart is stable
2.       Checkout loading has finished.

This means it’s not safe to lock UI by simply using deliveryModeSetInProcess$.
 
下圖紅線以上的三個請求，代表點選 Standard Delivery 之後的 HTTP 請求。

In general, the 1~3 HTTP requests above the red line in picture below represent the requests sent for Standard Delivery radio input click.

下圖紅線以下的三個請求，代表點選 Standard Delivery 之後的 HTTP 請求。

the 1~3 HTTP requests below the red line for Premium Delivery radio input click.
 
If user clicks Premimu Delivery radio input after timestamp t1, that is, after 3rd HTTP request for Standard Delivery is finished, we are safe.
 如果使用者在 t1 時間戳之後點選 Premium Delivery，這個時候是安全的。

![](https://img-blog.csdnimg.cn/img_convert/6dfad2aeec72ebbd86c7a3169c6a14e6.png)

Below is a happy path: t2 > t1

![](https://img-blog.csdnimg.cn/img_convert/c1b923d49624affe569670149aaad65a.png)

Bad path:
T0: HTTP PUT request has finished. Radio input is enabled again.
If user clicks radio input between (t0, t1), user can toggle between radio input multiple times, however no HTTP put request would be sent( cart should be stable, checkout loading should be false )
Based on Jerry’s observation: such HTTP put request will be queued and sent automatically until cartStable = true and checkout loading = false again.
~~Any user clicks after t1 will lead to concurrent HTTP PUT request sent to backend.~~

反之：在t1之前切換 input ，此時 input radio 不能被鎖住，但是點選並不會直接觸發 HTTP PUT 操作，而是被加到佇列裡。然後等 t1 到達時，這些請求像脫韁的頁碼一樣以併發的方式傳送出去了。

![](https://img-blog.csdnimg.cn/img_convert/ff82d8687c989540bfe813d05886428c.png)

Time sequence of Jerry’s testing
 
Test preparation: Premium Delivery is selected. Let’s say wait 20 seconds until all three HTTP request for it ( 1 PUT and 2 GET ) have finished.
 
Test sequence:
1.       Select “Standard delivery”. Radio input is disabled. Works as expected.
2.       Wait till Radio input is enabled again. Works as expected.
3.       Select “Premium delivery”. Due to issue, radio input is not disabled any more. At this time, click “Standard delivery” immediately.
Explain on the console.log:
Part1: radio input is disabled. HTTP put request is sent.

![](https://img-blog.csdnimg.cn/img_convert/4fadcd7e5a026713fc1b5c3d5b39ae6b.png)

Part2: radio input is enabled again.

![](https://img-blog.csdnimg.cn/img_convert/5d0d3f31fa27d4a02a75410dd381e7ae.png)

Part3: 16:57:02 HTTP GET request for “standard mode” is fired.
16:57:03 user clicks “premium delivery”. No HTTP PUT request will be sent.
 
![](https://img-blog.csdnimg.cn/img_convert/e4c99d1ee3197fc0ffd49e87f0c50018.png)

Part4: 16:57:04 “standard delivery” is selected. No HTTP put request is sent.

![](https://img-blog.csdnimg.cn/img_convert/86d501173b3901cd4049bb122b3c6406.png)

Part5: Only once CartStable becomes true and isLoading becomes false, the HTTP put requests are sent now.

![](https://img-blog.csdnimg.cn/img_convert/3688881fed43e94afad44d8b1c015071.png)

併發的 HTTP put 請求本身並不會出錯，但是會導致隨後的 HTTP GET 操作返回錯誤。
Concurrent HTTP PUT will cause errors in backend API execution:

![](https://img-blog.csdnimg.cn/img_convert/d08538d43ddb36d4ee89bc53c7cc3091.png)

SAP 電商雲 Spartacus UI 的 checkout 場景中的序列請求設計分析

相關文章