如果要做 Loading 的話，個人偏好全域處理，由 HttpInterceptor 統一攔截處理，不需要每個元件都設一個 isLoading 的參數來控制，不會有些一樣的行為只加了其中一部分，Loading 的樣式也可以統一設計，東一塊西一塊很難維護也很難協作。

什麼是 HttpInterceptor？

首先，我們需要理解 HttpInterceptor 的本質。它就像是一個「中間件」，位於你的應用程式和 HTTP 請求之間。HttpInterceptor 就像是應用程式的智慧偵測門，每當有 HTTP 請求要「出入」時，都必須通過這道門。

運作概念

出門時（Request）：

• 檢查身份證件（驗證 token）
• 配發通行證（添加 headers）
• 開啟監控系統（啟動 Loading）
• 記錄出門時間

回家時（Response）：

• 檢查攜帶物品（處理回傳資料）
• 偵測異常狀況（錯誤處理）
• 關閉監控系統（關閉 Loading）
• 記錄整個過程

應用程式組件              HttpInterceptor               後端API伺服器
┏━━━━━━━━━━━━━━━┓           ┏━━━━━━━━━━━━━━━┓          ┏━━━━━━━━━━━━┓
┃   Component   ┃           ┃               ┃          ┃            ┃
┃   Service     ┃ ──────▶  ┃   攔截請求     ┃ ──────▶ ┃  HTTP API  ┃
┃   http.get()  ┃           ┃   顯示Loading ┃          ┃  處理請求  ┃
┃               ┃ ◀──────   ┃   隱藏Loading ┃ ◀────── ┃  回傳資料  ┃
┗━━━━━━━━━━━━━━━┛           ┃   錯誤處理    ┃          ┗━━━━━━━━━━━━┛
                            ┗━━━━━━━━━━━━━━━┛
                                     ┃
                            ┏━━━━━━━━━━━━━━┓
                            ┃  全域Loading ┃
                            ┃  狀態管理    ┃
                            ┗━━━━━━━━━━━━━━┛

為什麼選擇 HttpInterceptor 處理 Loading？

1. 全域性和自動化處理
   最重要的優勢是它能夠自動攔截所有的 HTTP 請求。這表示你不需要在每個 Service 或 Component 中手動添加 Loading 邏輯。試想看看，如果你有 50 個不同的 API 呼叫，沒有 Interceptor 的話，你就需要在 50 個地方都寫一遍 Loading 的程式碼，光想就想離職。

   Angular 應用 → 🚪攔截器鏈 → 🌐 伺服器
                   ↗️ 去程：應用發出的所有 HTTP 請求
   
   Angular 應用 ← 🚪攔截器鏈 ← 🌐 伺服器  
                   ↖️ 回程：所有的 HTTP 回應
   

2. 關注點分離的優雅實現
   HttpInterceptor 體現了「單一職責原則」。你的業務邏輯組件只需要專注於處理資料和業務規則，而不用關心 Loading 狀態的管理。這就像是廚師專心做菜，而服務生負責上菜一樣，各司其職。

3. 統一的用戶體驗
   透過 Interceptor，你可以確保整個應用程式的 Loading 行為是一致的。無論是登入、載入用戶資料，還是提交表單，使用者看到的 Loading 效果都是統一的，這大大提升了使用者體驗的專業感。

踩雷處

如果是在lazyloading 的元件裡面直接使用 this.http.... 呼叫API，要記得不要重複匯入 HttpClientModule 不然會被覆蓋，攔截器沒辦法被正確繼承

補充

class-base interceptor 的寫法可以參考這篇