使用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"