ng best practices
1.0.0
このプロジェクトは、Angular Projectに基づいた具体的な例を使用して、フロントエンド開発（Web/モバイル）のベストプラクティスを紹介するチュートリアルのサポート例となることを目的としています。
チュートリアルを見るには、できるだけ早くここに投票できます。
このプロジェクトは、スタートアップやより伝統的な産業（金融および航空空間）を支援した経験の結果であり、フロントエンドプロジェクト（WebとMobule）を定義および開発しています。
製品を起動する際の最も難しい部品の1つは、ベストプラクティスを定義し、開発ワークフローを導入するための最良のツールを見つけることであることに気づきました。
そこで、私はこのプロジェクトを作成することを決めました。これは、箱から出る準備ができているベストプラクティスの集中であり、開発者や宇宙的な技術リード/テクニカルアーキテクトの日、さらにはプロジェクトに最適なワークフローを見つけて定義するための努力を節約することができます。
このプロジェクト/チュートリアルの主な焦点は、開発のベストプラクティスです。したがって、最初は、継続的な統合またはアプリケーションの展開に関連する資料は含まれません。
通知1：このプロジェクトに存在するベストプラクティスの多くは、前述のように、一般的なフロントエンド開発、さらには一般的な開発（フロントエンドだけでなく）でさえあります。
通知2：さまざまなプロジェクトの内容が、プロジェクトの進化と、特定のツール、ライブラリ、またはパターンをプロジェクトに追加/含める手順を理解することをお勧めします。
このプロジェクトは、Angular CLIバージョン7.3.1で生成されました。
このプロジェクトでは、主に糸を使用します。ただし、NPMを使用して同じスクリプト/コマンドを実行できます。
たとえば、 yarnを使用してプロジェクトを開始するにはyarn startを実行します。 npmを使用して同じことを行うにはnpm run startを実行できます。
このプロジェクトを起動できるようにするには、インストールする必要があります。
npmの代わりに異なるスクリプトを実行します。 （オプション）プロジェクトを開始する前に、さまざまな依存関係/ライブラリをインストールする必要があります。そうするために実行するには：
# if npm
npm install
# if yarn
yarn
以下は、プロジェクトの開発に一般的に必要なオプションのツールのリストです。
最新の作業コードとテスト済みコードを見つけることができるメインブランチはマスターです。
Develop Branchの日々のコミットと開発をフォローできます。
タグ付けシステムは、プロジェクトのさまざまなアップグレードとリリースに沿って行われます。
開発サーバーのyarn startを実行します。 http://localhost:4200/に移動します。ソースファイルを変更すると、アプリは自動的にリロードされます。
ng generate component component-name実行して、新しいコンポーネントを生成します。 ng generate directive|pipe|service|class|guard|interface|enum|module使用することもできます。
プロジェクトを構築するためにyarn build実行します。ビルドアーティファクトは、 dist/ディレクトリに保存されます。プロダクションビルドに--prodフラグを使用します。
実際、デフォルトのAngular-CLI生成プロジェクトは、単体テストにKarmaツールを使用します。 Karmaの問題（場合によっては利点になる可能性があります）は、多くの場合、テストを実行するためにブラウザを起動する必要があり、同時にテスト実行時間を延長する必要があることです。さらに、ブラウザを使用できる環境で実行される開発/配信プロセスに統合された継続的な統合がある場合があります。
冗談であるKarmaに興味深い代替品があります。テストをより速く簡単に作成できます。ブラウザは必要ありません。それには、組み込みのモッキングとアサーションの能力が付属しています。さらに、JESTはテストを並行して同時に実行し、よりスムーズで高速なテスト実行を提供します。
Jest-PreSet-Angular：Jest構成をより簡単にするために使用されます。実際の中古バージョンは6.0.2なので、このライブラリのFuturバージョンではドキュメントと構成が異なります。
yarn test:all 。
connection Project Run yarn test:connectionなどの特定のプロジェクトでユニットテストを実行する場合。必要なスクリプトをpackage.jsonファイルに追加することを忘れないでください。新しいライブラリでテストを起動できるようにするために、一致するJest構成ファイルにaddiionに追加します。 connectionライブラリに対してそれがどのように行われるかの例を見ることができます。
また、テストを起動し、Exmaple yarn test:all:watchのために実行することで変更を監視することもできます。
VSコードとJESTデバッグ： VSコードを使用する場合、 .vscodeフォルダーの下にlaunch.jsonファイルを追加してJestベースのユニットテストをデバッグできます（実際のレポでサンプルファイルを見つけることができます）。デバッガーは、内蔵ノードデバッガーを使用します。ここでは、より完全なドキュメントが好きです。
yarn e2eを実行して、プロトラクターを介してエンドツーエンドテストを実行します。
connectionライブラリからコンポーネントをインポートする場合は、 @connection Annotationを使用できます。
例： import { ConnectionModule } from '@connection' 。
これは、 tsconfig.jsonファイルへのpaths属性の追加のおかげで可能です。
"compilerOptions" : {
...,
"paths" : {
"@connection" : [
" projects/connection/src/public_api "
],
...
},
...
}パスについてより具体的に取得したい場合（たとえば、円形依存の場合）、次のようなtsconfig.jsonファイルに他のパスを追加できます。
"compilerOptions" : {
...,
"paths" : {
"@connection" : [
" projects/connection/src/public_api "
],
"@connection/*" : [
" projects/connection/src/* "
]
...
},
...
}次の例のように、コンポーネントまたはその他の角度エクスポートされた機能をインポートすることができます。
例： import { ConnectionComponent } from '@connection/lib/modules/main/pages'; ;
開発者がコードをコミットしてプッシュしながら正確な作業をフォローしていることを確認して、定義を行い、スクリプトを手動で実行する必要がないようにするには、次のツールが非常に便利です。
package.jsonで追加します：
" scripts " {
"commit" : " git-cz " ,
...
}したがって、 yarn commitを実行すると、 cz-cli使用されます。したがって、これ以上直接的なgit commitありません。
cz-cliプラグインを完成させることになります。 package.jsonで追加します：
"config" : {
"commitizen" : {
"path" : " node_modules/cz-customizable "
},
"cz-customizable" : {
"config" : " path/to/custom/cz-config.js "
}
},
... Configuration（ config.cz-customizable.config ）にカスタムファイルを提供しない場合、プロジェクトのルートに存在する.cz-config.jsファイルが使用されます。
注： VSコードを使用してGIT Commitコメントまたはその他のファイル操作タスクをデフォルトのvimの代わりに編集できるようにするには、 git config --global core.editor "code --wait"を実行できます。VSコードはCommande Lineから利用可能です（実行中のcode --helpで確認できます）。
詳細については、こちらです。
package.jsonファイルのルートにhusky構成を追加します。
"husky" : {
"hooks" : {
"pre-commit" : " yarn lintstaged " ,
"prepush" : " yarn prod "
}
}フールをスキップする場合は--no-verifyフラグをgitコマンドに追加するだけです。例： git push --no-verify
したがって、すでに定義されているhuskyフック構成に、 commit-msgフックを追加できます。
"husky" : {
"hooks" : {
...,
"commit-msg" : " commitlint -E HUSKY_GIT_PARAMS "
}
} commit-msg Hookを使用すると、作成する前にリントを並べることができます。
プロジェクトのルートにcommitlint.config.jsファイルを追加して、リントルール/慣習を定義できます。
commitlint.config.js例：
module . exports = {
// we use the default @commitlint/config-conventional rules.
// you have to install @commitlint/config-conventional library to be able to use it.
extends : [ '@commitlint/config-conventional' ] ,
// Any rules defined here will override rules from @commitlint/config-conventional
// => custom rules
rules : {
'header-max-length' : [ 2 , 'always' , 100 ] ,
'subject-case' : [
2 ,
'never' ,
[ 'sentence-case' , 'start-case' , 'pascal-case' , 'upper-case' ]
] ,
...
}
} ;注：同じ情報を再び入力する必要がないようにコミットを再試行したい場合はyarn commit:retry 。
角度のルーロジュールが使用されました。 Angularのドキュメントは非常に完全であり、それを見てください。
このプロジェクトでは、 app （StandAlone）プロジェクトでは、直接ルーティング/ロードを使用していることを選択しました。一方、メインアプリ（ルートアプリ）の場合、モジュールは怠zyなロードされており、ルーティングの仕組みに影響します。
方法を確認するには、Lzayのロードが処理される方法を確認するには、怠zyなロードされたモジュールが定義されているsrc/app/lazy Directoryをご覧ください。次に、これらのモジュールはsrc/app/app-routing.module.tsファイル内に「本当に」怠zyなロードされます。怠zyなロードされた各モジュールについて、パスが定義されています。このパスは、元のモジュールで定義されているすべてのパスを先行する必要があります。
Epemple：Orignalモジュールでは、url localhost:4200/page-oneを介してpage-oneコンテンツにアクセスしてください（アプリ/スタンドアロンプロジェクトのように）。同時に、あなたが同じモジュールを怠zyなロードするために定義したパスはmy-lazy-loaded-pathです。そのため、同じコンテンツ/ページにアクセスするには、代わりにURL localhost:4200/my-lazy-loaded-path/page-oneを使用する必要があります。
そして、ここでは、怠zyなロードまたは直接ロード中にモジュールを機能させるために、ロードされたモジュールと環境変数を介したforRootメソッドの組み合わせを使用します。
フォームの操作に関しては、Angularでは、反応的な形とテンプレート駆動型の形式のどちらかを選択できます。
公式の角度文書では、見つけることができます。
反応的なフォームはより堅牢です：それらはよりスケーラブルで、再利用可能で、テスト可能です。フォームがアプリケーションの重要な部分である場合、またはアプリケーションを構築するためにリアクティブパターンを既に使用している場合は、リアクティブフォームを使用してください。
テンプレート駆動型フォームは、メーリングリストのサインアップフォームなど、アプリにシンプルなフォームを追加するのに役立ちます。アプリに追加するのは簡単ですが、リアクティブなフォームと同様にスケーリングしません。テンプレートでのみ管理できる非常に基本的なフォーム要件とロジックがある場合は、テンプレート駆動型のフォームを使用してください。
ここで重要な違いの表を見つけることができます。
このプロジェクトでは、ストリクターデータモデルを持っているか、テンプレート（ビュー/HTML）とコントローラー（コンポーネントクラス/モデル）間の同期性を利用するなど、すべての利点に反応フォームを使用することを選択しました。その上、一般的に、大きなプロジェクトでは、複雑な形式を持っている可能性があり、 reactive formsにより、タスクが簡単に構築されます。
プロジェクトを起動すると、最初に既存のスタイリングライブラリに基づいています。アプリケーションをスタイリングするときの時間を節約するのに役立ちます。
以下は、使用できるライブラリの例をいくつか紹介します。
実際、このプロジェクトでは、使用されたbootstrapです（ ng-boostrapではなく）。
React、Angularなどのほとんどのライブラリは、コンポーネントが外部ライブラリやツールを必要とせずに状態を内部的に管理する方法で構築されています。コンポーネントが少ないアプリケーションには適していますが、アプリケーションが大きくなるにつれて、コンポーネント間で共有される管理状態が雑用になります。
データがコンポーネント間で共有されるアプリでは、状態がどこに住むべきかを実際に知ることが混乱するかもしれません。理想的には、コンポーネント内のデータは1つのコンポーネントだけに存在する必要があります。したがって、兄弟コンポーネント間でデータを共有することは困難です（ソース）。
州の管理ライブラリの動作方法は簡単です。アプリケーションの状態全体を保持する中央の店があります。各コンポーネントは、あるコンポーネントから別のコンポーネントに小道具を送信することなく、保存状態にアクセスできます。
たとえば、Reactの場合、最も使用される州管理ライブラリの1つはReduxです。また、React-Reduxパッケージを使用すると、簡単になります。確かに、Facebookのフラックスのようなreactのための他の州の管理ライブラリがあります。したがって、 reduxがfluxを使用していることを最もよく知っているものを選択してください。これは、 reactに集中せず、他のビューライブラリと一緒に使用できるためです。
angularの場合、次のような州管理のための多くのオプションがあります。
Angularの場合、さまざまなオプションを研究した後、 ngxs最良のオプションであることがわかります。 Angularのために最初に書かれているため、Angularのコードスタイルに従って実装され、 Angularが提供するDependency Injectionの範囲と範囲を取ります。さらに、他のライブラリよりも冗長です。これらの理由から、私たちは一緒に働いた多くの企業でそれを使用することを選択しました。 ngxs使用する理由の完全な説明については、ここで見つけることができます。
このリポジトリに使用されたngxsプラグイン：
ファサードパターンは、オブジェクト指向プログラミングで一般的に使用されるソフトウェア設計パターンです。アーキテクチャのファサードと同様に、ファサードは、より複雑な基礎または構造コードをマスキングする前面のインターフェイスとして機能するオブジェクトです。ファサードは：
これはかなり些細な変化（および余分なレイヤー）のように思えますが、ファサードは開発者の生産性に大きなプラスの影響を与え、ビューレイヤーの複雑さが大幅に低下します（ソース）。
他の利点は、使用することを選択した州管理ライブラリとは独立した、コントローラー（たとえば角度コンポーネント）を作成することです。
国際化には、2つのオプションがあります。
1- Angularのi18nシステムを使用します
2 -NGX -Translateライブラリを使用します。
私は詳細には触れませんが、このプロジェクトとプロジェクトのような他の多くの制作の選択は、 ngx-translate使用することでした。主な理由は、同じ結果について、使用および開発がより簡単であり、 Angular i18n言語ごとのアプリケーションを構築することを強制し、言語の変更に関するアプリケーションをリロードすることです。
Angular CLIをng helpしてより多くのヘルプを取得するには、ang ang cli readmeをチェックしてください。
VSコードを使用している場合は、次のプラグインが非常に役立つ場合があります。
@haythem-ouederniによる著作権。すべてのプロジェクトソースは、Apacheライセンスライセンスに基づいてリリースされます。
