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 disabledThe 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的原创文章，尽在："汪子熙":