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 已经处于可用状态了。
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 页面会自动触发一个 HTTP put 请求：
What is preferred delivery mode?
It’s returned by CheckoutConfigService.getPreferredDeliveryMode:
Preferred delivery mode 也是通过一个方法调用返回的：
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 页面，重新触发 address 的加载逻辑(API 调用)：
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.
现在就能看到 spinner 效果了。但是现在的实现里，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 操作结束之前，input 和 continue 按钮必须处于 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 ).如果直接进入 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.
