What is behavior before Jerry’s fix

The chapter below described the behavior BEFORE Jerry’s fix.

Scenario1

First step of checkout: shipping address page
url: http://localhost:4299/electronics-spa/en/USD/checkout/shipping-address

當我們直接訪問這個頁面時，delivery mode 提前從后臺加載。

When we directly access this page, the delivery mode is being fetched from backend in advance.
See file checkout.effect.ts below:

This means, in this case, if we press “Continue” page in Shipping Address step, there will be NO spinner displayed in Delivery Mode page, since the required delivery mode data is already pre-fetched and available.

此時點擊 continue 按鈕，大概率是不會有 spinner 顯示的，因為 delivery mode 已經(jīng)處于可用狀態(tài)了。

Summary:
In this scenario ( when we first access shipping address page, and press continue to reach shipping method page, most probably we will NOT see spinner in shipping method page,

When we reached Shipping method page, there is a HTTP PUT request sent automatically, with preferred delivery mode preselected.
This request is sent by code below: delivery-mode.component.ts

在 shipping method 頁面會自動觸發(fā)一個 HTTP put 請求：

What is preferred delivery mode?
It’s returned by CheckoutConfigService.getPreferredDeliveryMode:

Preferred delivery mode 也是通過一個方法調(diào)用返回的：

By the way, if we press back button in shipping method page, the shipping address page will be displayed again.
The ngOnInit hook will be executed, within this hook this.userAddressService.loadAddresses will be called, which triggers the address loading from backend again. Thus we could see a spinner in Shipping address page again.

如果我們點擊 back，會重新回到 address 頁面，重新觸發(fā) address 的加載邏輯(API 調(diào)用)：

Scenario2

通過 url 直接進入 delivery mode 頁面：

We directly go to step2 – shipping method page via url:
http://localhost:4200/electronics-spa/en/USD/checkout/delivery-mode
In this case, since supported delivery mode has no chance to be pre-loaded by shipping address page, so it’s being loaded now. We could see spinner now.

現(xiàn)在就能看到 spinner 效果了。但是現(xiàn)在的實現(xiàn)里，spinner 并沒有覆蓋到 continue 和 back 按鈕，這個問題需要修復。

However, the back and continue buttons are NOT covered by spinner, this is not good, as it’s not consistent with other steps. We have to fix it.

The Continue button is disabled, since no delivery mode is selected.

Behavior after Jerry’s fix

Fix target:

修復目標：

Scenario1: navigate from shipping address page to shipping method page

As described before, in this case the supported delivery mode is already pre-loaded by shipping address page, so we will NOT see spinner in shipping method page.
And since there’s HTTP put request sent automatically, before this request finished:

• The radio input control is disabled
• The continue button is disabled

在 HTTP put 操作結(jié)束之前，input 和 continue 按鈕必須處于 disabled 狀態(tài)：

Figure: the radio input and continue button are disabled when there’s ongoing HTTP put request

Scenario2: direct navigate to shipping method page via url

http://localhost:4200/electronics-spa/en/USD/checkout/delivery-mode

In this case, supported delivery mode are being loaded. We can see spinner, and the spinner already convers both radio input and two buttons(back & continue ).

如果直接進入 delivery mode 頁面，spinner 需要能覆蓋掉 continue 和 back 按鈕：

Summary

• When we navigate from shipping address page to shipping method page, we will NOT see spinner in latter. The preferred delivery mode is automatically set in UI. There is one HTTP PUT request sent to backend automatically. Before the request finished, both radio input for delivery mode and continue button are disabled.
• When we directly navigate to shipping method page, we will see spinner displayed when the request for supported delivery mode does not finish. During this time, the spinner convers both radio input and continue button & back button.

更多Jerry的原創(chuàng)文章，盡在：“汪子熙”:

總結(jié)

以上是生活随笔為你收集整理的SAP 电商云 Spartacus UI 的 checkout 设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。