LoaderState：
loading 状态在 true 和 false 之间的切换，通过 loader
.reducer.ts 里的 reducer 函数进行。每次通过 store.dispatch 往 store 里投递新的 action 时，都会触发该 reducer 的执行。
添加上打印日志：
设置 delivery mode 的用户点击，触发一个 put 请求，两个 get 请求：
4秒的 proces 从 loading 到 loaded
2秒的 Multi Cart Data 从 loading 到 loaded
3秒的 Checkout Details 从 loading 到 loaded
为什么会打印两次？
从时间轴能看出是串行关系：
HTTP PUT 先执行完，然后才是 cart 数据的读取。
完整的时间轴：
逐一解答。
process
当我点击 radio input 之后，通过了下图 245 行 filter projection 的考验之后，进入 251 行 store.dispatch 操作。因此，如果当前 cart 不 stable，并且 checkout Service 处于 loading 状态时， 不会执行到 251 行：
当前 isLoading 为 false，只有这样才能通过 245 行的 filter 操作：
checkout Store 是构造函数依赖注入的 store API.
所以 process 就是 setDeliveryMode 的 entity 类型。
上图的 dispatch 操作，居然会触发到我应用代码里的 tap hook. 这是期望中的行为，因为 deliveryModeSetInProcess 通过 combineLatest 返回，从语义上说，checkoutService 的 loading 状态，和 Checkout Delivery Service 的 getSetDeliveryModeProcess 方法，只要有任意发生变化，都会触发 deliveryModeSetInProcess$ 的 subscribe 执行。
这个常量好面熟：
tap 这里为什么是 true？
因为这里是 true：
会调用两次，打印第二次 tap hook。如果不用 combineLatest，会不会还是有这个行为？
标志着 delivery mode set 完成：
tap hook 再次触发：
这次就看不到明显的是通过 application code 来触发的痕迹：
并不是通过下图这段代码触发的：
紧接着，开始 load cart 数据了：Multi Cart Data
