国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

使用Angular CLI時的6個最佳實踐和專業(yè)技巧

atinosun / 2658人閱讀

摘要:在官方庫的多主題中進行有效的使用。項目中默認選擇使用可以假設是安全的。常規(guī)提交定義了強制類型可選范圍其次是提交消息。標準版本將正確地撞擊項目的主要版本,因為在提交主體中存在著關鍵字。

使用Angular CLI開發(fā)angular應用程序是一種非常愉快的體驗!Angular團隊為我們提供了令人驚嘆的CLI,它支持了任何重要項目開箱即用所需的大部分東西。

規(guī)范化的項目結構與全面的測試能力(包括單元測試和端到端測試),腳手架,支持使用特定的環(huán)境配置去構建產品。這在構建每一個新項目時候節(jié)約了大量時間。感謝Angular團隊!?

雖然Angular CLI的工作的很好,但我們可以利用一些潛在的配置和最佳實踐使我們的項目更好!

我們將要學習什么?

具有Core(核心),Shared(共享),lazy-loaded Feature modules(延遲加載功能模塊)體系結構的最佳實踐

為app和environments文件夾使用別名來支持更干凈的導入

為什么和如何使用Sass ,Angular Material

如何組織好的產品構建方式

如何向PhantomJS說再見以及使用Headless Chrome來替代(測試)

如何發(fā)布我們的項目通過自動生成更新日志和正確的版本號

1. 關于項目的的文件結構

好的, 我們使用Angular CLI生成了新的項目,但是現在呢?我們應該繼續(xù)在一些隨機文件夾生成我們的服務和組件嗎?我們應該如何組織我們的項目?

一個好的指導原則應該是遵循將應用程序分成至少三個不同的模塊:?Core(核心模塊), Shared(共享模塊) 和 Feature(功能模塊) (不過我們可能需要更多的功能模塊。?).

核心模塊

所有服務都應該在核心模塊實現。典型的例子比如認證服務或用戶服務。讓我們看個例子。

/* 3rd party libraries */
import { NgModule, Optional, SkipSelf } from "@angular/core";
import { CommonModule } from "@angular/common";
import { HttpClientModule } from "@angular/common/http";

/* our own custom services  */
import { SomeSingletonService } from "./some-singleton/some-singleton.service";

@NgModule({
  imports: [
    /* 3rd party libraries */
    CommonModule,
    HttpClientModule,
  ],
  declarations: [],
  providers: [
    /* our own custom services  */
    SomeSingletonService
  ]
})
export class CoreModule {
  /* make sure CoreModule is imported only by one NgModule the AppModule */
  constructor (
    @Optional() @SkipSelf() parentModule: CoreModule
  ) {
    if (parentModule) {
      throw new Error("CoreModule is already loaded. Import only in AppModule");
    }
  }
}
共享模塊

所有的“dumb(啞)”組件和管道都應該在這里實現。這些組件不能從核心模塊或其他特性模塊的構造函數中的導入和注入服務。它們應該使用組件的模板中的屬性接收所有數據。這一切都歸結到這一事實,SharedModule(共享模塊)沒有任何依賴于我們的應用程序的其余部分。

這也是導入和重新導入Angular Material 組件庫的完美場所。

/* 3rd party libraries */
import { NgModule } from "@angular/core";
import { CommonModule } from "@angular/common";
import { FormsModule  } from "@angular/forms";
import { MdButtonModule } from "@angular/material";

/* our own custom components */
import { SomeCustomComponent } from "./some-custom/some-custom.component";

@NgModule({
  imports: [
    /* angular stuff */
    CommonModule,
    FormsModule,

    /* 3rd party components */
    MdButtonModule,
  ],
  declarations: [
    SomeCustomComponent
  ],
  exports: [
    /* angular stuff */
    CommonModule,
    FormsModule,

    /* 3rd party components */
    MdButtonModule,

    /* our own custom components */
    SomeCustomComponent
  ]
})
export class SharedModule { }
如何使用Angular CLI編寫項目結構

我們可以在創(chuàng)建新項目后立即生成核心和共享模塊。這樣,我們就可以從一開始就準備生成額外的組件和服務。

運行命令ng generate module core生成核心模塊。然后在core文件夾創(chuàng)建index.ts文件,再重新導出CoreModule。我們將重新導出額外的公共服務,這些服務在整個開發(fā)過程中都可以使用。

完成后,我們可以對shared module(共享模塊)執(zhí)行同樣的操作。

功能模塊

我們將為應用程序的每一個獨立特性創(chuàng)建多個功能模塊。Feature modules(功能模塊)應該只能從CoreModule導入服務。如果功能模塊A需要從功能模塊B導入服務,可以考慮將該服務遷移到CoreModule。

在某些情況下,需要只是某些功能模塊共享的服務,將它們移動到核心是沒有意義的。在這種情況下,我們可以創(chuàng)建特殊的共享功能模塊,如本文后面所述。

經驗法則是: 我們創(chuàng)建的功能模塊盡量不依賴其他功能模塊,僅僅服務由CoreModule提供,組件由SharedModule提供

這將保持我們的代碼干凈,易于維護和擴展的新功能。它還減少了重構所需的工作量。如果遵循得當,我們將確信對一個功能的更改不會影響或破壞我們的應用程序的其余部分。

延遲加載

我們應該盡可能延遲加載我們的功能模塊。理論上,只有一個功能模塊應該在應用程序啟動時同步加載以顯示初始內容。每個其他功能模塊應該在用戶觸發(fā)導航后緩慢加載。

2. app 和 environments 的別名使用

我們的app 和 environments文件夾使用別名將使我們能夠實現干凈的導入,在我們的應用程序這將是一致的。

假設,但通常情況。我們正在研究一個組件,它位于功能模塊A中的三個文件夾深處,我們希望從核心模塊中導入位于兩個文件夾深處的服務。這將導致導入聲明看起來有點像import { SomeService } from "../../../core/subpackage1/subpackage2/some.service"

絕對不是最干凈的導入申明…

更糟糕的是,每當我們想改變這兩個文件中任何一個的位置時,我們的導入語句都會中斷。相比之下,更短的導入申明import { SomeService } from "@app/core"。看起來更好,不是嗎?

能夠使用別名必須添加URL地址和路徑屬性,我們tsconfig.json文件像這樣…

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

我們還添加了@env別名,以便能夠從import { environment } from "@env/environment"中使用同一個導入申明輕松地從應用程序的任何地方訪問環(huán)境變量。它將為所有指定的environments工作,因為它將根據傳遞給ng build命令的--env標志自動解析正確的環(huán)境配置文件。

通過我們的路徑,我們現在可以像這樣導入environment 和 services …

/* 3rd party libraries */
import { Component, OnInit } from "@angular/core";
import { Observable } from "rxjs/Observable";

/* globally accessible app code (in every feature module) */
import { SomeSingletonService } from "@app/core";
import { environment } from "@env/environment";

/* localy accessible feature module code, always use relative path */
import { ExampleService } from "./example.service";

@Component({
  /* ... */
})
export class ExampleComponent implements OnInit {
  constructor(
    private someSingletonService: SomeSingletonService,
    private exampleService: ExampleService
  ) {}
}

在上面的例子中,你也許注意到我們直接導入服務SomeSingletonService是通過@app/core,代替了@app/core/some-package/some-singleton.service。這得感謝核心模塊的入口文件index.ts重新導出了每一個公共實體。我們在每一個包(文件夾)都創(chuàng)建了一個文件index.ts,它看起來像這樣...

export * from "./core.module";
export * from "./auth/auth.service";
export * from "./user/user.service";
export * from "./some-singleton-service/some-singleton.service";

在大多數的應用程序中,特殊功能模塊的組件和服務的通常只需要訪問服務的 CoreModule 和組件的SharedModule。有時這可能不足以解決特定的業(yè)務情況,我們還需要某種“shared feature module(共享功能模塊)”,它為其他功能模塊的有限子集提供功能。

在這種情況下,我們將得到類似的東西import { SomeService } from "@app/shared-feature";。和核心模塊一樣,共享功能模塊使用別名@app進行訪問。

3. 使用SASS

SASS是一個CSS的預處理器,支持有趣的東西,像variables(盡管CSS將要實現變量),functions,mixin等等。

SASS在Angular Material Components官方庫的多主題中進行有效的使用。項目中默認選擇使用SASS可以假設是安全的。

為了使用SASS我們在使用Angular CLI生成我們的項目時候必須用命令ng new command --style scss 。這就設置了大部分必須的配置。默認情況下不添加stylePreprocessorOptions includePaths,我們可以自己設置成根目錄 "./" 和 可選的 "./themes"。

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

這有助于我們的編輯器找到導入標志,并且通過Angular Material的變量和工具函數的代碼完成來增強開發(fā)人員的體驗。

When theming Angular Material apps it’s a good practice to extract theme definitions into separate themes folder, one theme per file.

4. 應用產品構建

Angular CLI聲稱的項目只提供了一個非常簡單開箱即用的構建腳本ng build。為了生成產品級的工件,我們必須自己做一些定制。

我們在package.json中添加腳本"build:prod": "ng build --target production --build-optimizer --vendor-chunk"

Target Production

這是一個標志能使代碼壓縮,以及還有很多默認的有用的構建標志。使用如下:

--environment prod —使用 environment.prod.ts 文件設置環(huán)境變量

--aot?—預編譯,提前編譯. 這將在未來的Angular CLI是默認設置,但是現在我們必須手動啟動。

--output-hashing all?—?將生成的文件的散列內容添加到文件名中,以方便瀏覽器緩存破壞(文件內容的任何更改都會導致不同的哈希值,因此瀏覽器被迫加載新版本的文件)

--extract-css true?—?將所有的css提取到到多帶帶的樣式表文件

--sourcemaps false?—?禁用source maps的生成

--named-chunks false?—?禁用使用可讀的名字,用數字替代

Other useful flags

--build-optimizer?—?新的功能,導致更小的捆綁,但更長的構建時間,所以慎用!(將來也應該默認啟用)

--vendor-chunk?—?將所有第三方(庫)代碼提取到多帶帶的塊中

去官方文檔檢查其他有用的配置項,也許在個人項目中用得上。

5. Phantom JS 死了! Headless Chrome 永存!

PhantomJS是一個非常著名的無頭的瀏覽器。這是事實上的解決方案,在CI服務器和許多開發(fā)機器上運行前端測試。

雖然有好的,這是現代ECMAScript支持滯后。更重要的是,它是不規(guī)范的行為,在許多情況下導致頭痛,當測試通過本地沒有問題,但他們仍然在CI環(huán)境出現問題。

幸運的是,我們不再需要處理它了!

就像官方文檔說的一樣…

Headless Chrome 是在Chrome 59上運行。這是在Headless環(huán)境下運行Chrome瀏覽器的一種方式。本質上,運行沒有Chrome的Chrome!它將Chrome和閃爍渲染引擎提供的所有現代Web平臺特性帶到命令行。

很棒,那我們在Angular CLI上使用它呢?

我們在package.json上添加腳本"test": "ng test --browser ChromeHeadless --single-run""watch": "ng test --browser ChromeHeadless"

很簡單,對吧!

6. 使用標準的提交信息 & 自動生成更新日志

對我們感興趣的項目的新特性和bug修復有一個快速概述總是很棒的。

讓我們?yōu)橛脩籼峁┩瑯拥谋憷?/em>

手動寫更改日志將是極其繁瑣,而且容易出錯的任務,所以它最好是自動化的過程。有很多可用的工具可以做這項工作,但是讓我們看下standard-version。

這個工具根據Conventional Commits specification把所有提交自動生成和更新changelog.md文件,并且正確地確定我們項目的新版本。

常規(guī)提交定義了強制類型、可選(范圍):其次是提交消息。還可以添加可選的正文和頁腳,它們都由空行分隔。讓我們來看看ngx-model庫所有提交信息的一個實踐例子。

fix(dependency): multiple versions of rxjs in single project (TS90010)

BREAKING CHANGE: rxjs is now peerDependency instead of dependency

closes #1

標準版本將正確地撞擊(bump)項目的主要版本,因為在提交主體中存在著BREAKING CHANGE關鍵字。

生成的 CHANGELOG.md 文件將像這個樣子….

看起來很好!那么我們如何在我們的項目中使用它呢?

首先我們需要通過命令npm install -D standard-version安裝到devDependencies ,然后添加腳本"release": "standard-version"到package.json文件中。

我們也可以通過git pushnpm publish使整個過程自動化。本例子中使用腳本"release": "standard-version && git push?—?follow-tags origin master && npm publish"

注意我們使用&&鏈接命令是平臺相關的,只能在基于Unix的系統(tǒng)上(因此也對Windows Cygwin,gitbash,或新的win10)。

附贈 Use resource root (Intellij IDEA, Webstorm only)

IntelliJ IDEA永遠不會找到所有默認情況下(帶有錯誤的標記和殘廢的紅色代碼)的路徑。幸運的是,解決方案非常簡單。只需選擇SRC文件夾并將其標記為Sources Root。

很棒! 你終于讀完了它!

我希望你能找到一些有用的技巧和最佳實踐!請支持這篇文章,以便向更多的受眾傳播這些建議!

參考資源

6 Best Practices & Pro Tips when using Angular CLI

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/90257.html

相關文章

  • 前端每周清單半年盤點之 Angular

    摘要:延伸閱讀學習與實踐資料索引與前端工程化實踐前端每周清單半年盤點之篇前端每周清單半年盤點之與篇前端每周清單半年盤點之篇 前端每周清單專注前端領域內容,以對外文資料的搜集為主,幫助開發(fā)者了解一周前端熱點;分為新聞熱點、開發(fā)教程、工程實踐、深度閱讀、開源項目、巔峰人生等欄目。歡迎關注【前端之巔】微信公眾號(ID:frontshow),及時獲取前端每周清單;本文則是對于半年來發(fā)布的前端每周清單...

    LeviDing 評論0 收藏0
  • 前端資源分享-只為更好前端

    摘要:一團隊組織網站說明騰訊團隊騰訊前端團隊,代表作品,致力于前端技術的研究騰訊社交用戶體驗設計,簡稱,騰訊設計團隊網站騰訊用戶研究與體驗設計部百度前端研發(fā)部出品淘寶前端團隊用技術為體驗提供無限可能凹凸實驗室京東用戶體驗設計部出品奇舞團奇虎旗下前 一、團隊組織 網站 說明 騰訊 AlloyTeam 團隊 騰訊Web前端團隊,代表作品WebQQ,致力于前端技術的研究 ISUX 騰...

    zxhaaa 評論0 收藏0
  • 前端資源分享-只為更好前端

    摘要:一團隊組織網站說明騰訊團隊騰訊前端團隊,代表作品,致力于前端技術的研究騰訊社交用戶體驗設計,簡稱,騰訊設計團隊網站騰訊用戶研究與體驗設計部百度前端研發(fā)部出品淘寶前端團隊用技術為體驗提供無限可能凹凸實驗室京東用戶體驗設計部出品奇舞團奇虎旗下前 一、團隊組織 網站 說明 騰訊 AlloyTeam 團隊 騰訊Web前端團隊,代表作品WebQQ,致力于前端技術的研究 ISUX 騰...

    JouyPub 評論0 收藏0
  • 前端資源分享-只為更好前端

    摘要:一團隊組織網站說明騰訊團隊騰訊前端團隊,代表作品,致力于前端技術的研究騰訊社交用戶體驗設計,簡稱,騰訊設計團隊網站騰訊用戶研究與體驗設計部百度前端研發(fā)部出品淘寶前端團隊用技術為體驗提供無限可能凹凸實驗室京東用戶體驗設計部出品奇舞團奇虎旗下前 一、團隊組織 網站 說明 騰訊 AlloyTeam 團隊 騰訊Web前端團隊,代表作品WebQQ,致力于前端技術的研究 ISUX 騰...

    vslam 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<