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

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.

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

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

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.

Scenario2

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.
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

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

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 ).

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的原創文章，盡在：“汪子熙”:

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的关于 SAP 电商云 Spartacus UI checkout 流程的一些讨论的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。