使用Angular CLI時的6個最佳實踐和專業技巧 學習總結

原文地址

• 組織項目文件結構

  三個不一樣的模塊： Core(核心模塊), Shared(共享模塊) 和 Feature(特性模塊);

  • 核心模塊(CoreModule):
    全部服務都應該在覈心模塊實現。典型的例子好比認證服務或用戶服務。
  • 共享模塊(ShareModule):
    全部的簡單組件和管道都應該在這裏實現。共享模塊沒有任何依賴於咱們的應用程序的其他部分。好比Angular Material 等其餘UI組件庫的按需導入而後重導入;
  • 特性模塊(FeatureModule):
    咱們將爲應用程序的每個獨立特性建立多個特性模塊。特性模塊應該只能從核心模塊導入服務。若是特性模塊A須要從特性模塊B導入服務，能夠考慮將該服務遷移到CoreModule。

在某些狀況下，須要只是某些功能模塊共享的服務，將它們移動到核心是沒有意義的。在這種狀況下，咱們能夠建立特殊的共享功能模塊，如本文後面所述。
遵循的經驗是： 咱們建立的功能模塊儘可能不依賴其餘功能模塊，僅僅服務由CoreModule提供，組件由SharedModule提供

這將保持咱們的代碼乾淨，易於維護和擴展的新功能。它還減小了重構所需的工做量。若是遵循得當，咱們將確信對一個功能的更改不會影響或破壞咱們的應用程序的其他部分。

延遲加載:
咱們應該儘量延遲加載咱們的功能模塊。理論上，只有一個功能模塊應該在應用程序啓動時同步加載以顯示初始內容。每一個其餘功能模塊應該在用戶觸發導航後緩慢加載。**只有設計做爲着陸的模塊是須要當即加載的，其餘模塊應該使用懶加載**

• app 和 environments 的別名使用

  • 避免導入路徑過長

    例如import { SomeService } from '../../../core/subpackage1/subpackage2/some.service'。

  • 解決方案在tsconfig.json中使用別名路徑;

    #tsconfig.json
        {
          "compilerOptions": {
            "...": "reduced for brevity",
            
            "baseUrl": "src",
            "paths": {
              "@app/*": ["app/*"],
              "@env/*": ["environments/*"]
            }
          }
        }

• SASS

  • 默認狀況下不添加stylePreprocessorOptions includePaths，咱們能夠本身設置成根目錄 "./" 和 可選的 "./themes"。

    #angular.json
    {
          "apps": [
            {
              "...": "reduced for brevity",
              
              "stylePreprocessorOptions": {
                "includePaths": ["./", "./themes"]
              }
            }
          ]
    }

• 構建階段

  • Target Production
    這是一個標誌能使代碼壓縮，以及還有不少默認的有用的構建標誌。使用以下：

    --environment prod —使用 environment.prod.ts 文件設置環境變量
    --aot —預編譯，提早編譯. 這將在將來的Angular CLI是默認設置，可是如今咱們必須手動啓動。
    --output-hashing all — 將生成的文件的散列內容添加到文件名中，以方便瀏覽器緩存破壞（文件內容的任何更改都會致使不一樣的哈                    
    希值，所以瀏覽器被迫加載新版本的文件）
    --extract-css true — 將全部的css提取到到單獨的樣式表文件
    --sourcemaps false — 禁用source maps的生成
    --named-chunks false — 禁用使用可讀的名字，用數字替代

  • Other useful flags

    --build-optimizer — 新的功能，致使更小的捆綁，但更長的構建時間，因此慎用！（未來也應該默認啓用）
    --vendor-chunk — 將全部第三方（庫）代碼提取到單獨的塊中

    去官方文檔檢查其餘有用的配置項，也許在我的項目中用得上。

• 使用標準的提交信息 & 自動生成更新日誌

  • standard-version

    這個工具根據 [Conventional-Commits-specification][3] 把全部提交自動生成和更新changelog.md文件
    而且正確地肯定咱們項目的新版本。

  • 如何使用

    npm install -D standard-version, 而後添加腳本"release": "standard-version"到package.json文件中。
    例如："release": "standard-version && git push — follow-tags origin master && npm publish"