GSS 技術部落格

在這個園地裡我們將從技術、專案管理、客戶對談面和大家分享我們多年的經驗，希望大家不管是喜歡或是有意見，都可以回饋給我們，讓我們有機會和大家對話並一起成長！
若有任何問題請來信：gss_crm@gss.com.tw

3 分鐘閱讀時間 (534 個字)

字體大小: + –

Angular #34 - 深入 Routing [7]

程式語言前端

2021/07/01, 週四

977 點擊

0 評論

Routing Best Pratices
- 根據前人的經驗，URL 的設計本身是很重要的，以下就提幾種:
  - URL 愈短愈好
    - 這個有點難控制，畢竟當功能愈來愈多的時候就有可能失控
    - 不過這也是一個反思，這一個 route 是否承擔過多的責任
  - 多用 Path variable，少用 Query Parameters
    - 如果是資源 ID 類的大部份都會是透過 Path Variable(如果是符合標準的 REST API 的話)
    - 只有暫時性的查詢參數才會透過 Query Parameters 的型式傳遞
  - 可以的話，命名完整一點
    - 雖然說 URL 愈短愈好，但那不代表每個字都要縮寫
    - 除非是真的非常常見的縮寫，不然不要假設大家都會縮
  - 有多個字的時候，用 hyphen(-)將字串起來
    - 舉例(/forums/2-introductions/89-cloneddidactic-knowledge-use)
    - 肉眼上比較好區分也容易閱讀
    - 除了可讀性之外，在解析時也比較好透過 split 之類的處理
  - 有限度的使用 Secondary Route
    - 前面有提過，太多會增加複雜度，畢竟它非主要的商業邏輯
    - 如果真的要用 OnInit 跟 OnDestroy 一定要好好定義，不要造成 memory leak，或是卡在畫面上造成 UX 不佳
  - 謹慎選擇要使用哪一種 Route Guard
    - 前面有提過 Guard 有五種，何時要用哪種要仔細思考
    - 如果真的不知道怎麼用，至少各 route 存取要加 canActivate，其他的可以上網參考別人的作法
  - Module 可以的話依商業邏輯切割，或是依功能切分
    - 如此便能善用 Lazy Loading 提高效能
    - 話雖如此，也不用一開始就切得一乾二淨，事後再搬移也可行，不要為了切割而切割，反而會太過於混亂，盡量保持高內聚低耦合既可
  - 愈簡單愈好
    - 如果 10 個 route 就夠了，那就不用 100 個
    - 愈多愈難管理，且容易作法容易分歧
小結:
- Routing 就到這兒了，目前為止我們學會了:
  - ActivatedRoute, Router, Routes, Params
  - 基本的 Routing => path 對上 component
  - Child routes => 可以搭配 path variable
  - Secondary routes => 獨立
  - Feature module => 高內聚低耦合
- 下一篇開始將講解 Directive 與 Pipe