SAP 电商云 Spartacus UI 的 checkout 场景中的串行请求设计分析

2022 年 9 月 19 日
四川
本文字数：2814 字
阅读完需：约 9 分钟

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 请求发送往后台。

这个串行请求的行为，从 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.

模式修改的触发，从 service 类的 setDeliveryMode 开始。

The call will be delegated to service class below:

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：

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=USDtrigged 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 数据：

当前设计的缺陷

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:

通过 Actions 执行 setDeliveryMode 的行为是受保护的，仅当 Cart stable 并且 isLoading 为 false 时才执行：

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

在 3G 慢速网络下测试会出现问题。

Test under slow 3G network, we have trouble now.

复现场景

Expected behavior: radio input is disabled again.Current behavior: radio input is NOT disabled.

The following is time sequence after standard delivery input is clicked again ( test step 4 described above )

Totally 5 seconds passed after user clicks “standard delivery”, unfortunately.

Currently, we disable radio input by deliveryModeSetInProcoess$. However, its value could only be changed when there’s a HTTP PUT request sent tobackend.

deliveryModeSetInProcoess$ 的值只有 HTTP put 操作发送之后，才有机会被修改。

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

复制代码

而 HTTP put 有两个外部依赖：

As explained above, HTTP PUT request sending has two external dependencies:

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，这个时候是安全的。

Below is a happy path: t2 > t1

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 到达时，这些请求像脱缰的页码一样以并发的方式发送出去了。