Angular プロジェクトを整理するにはどうすればよいですか?次の記事では、Angular プロジェクトを管理するための 5 つの実践的なヒントをまとめて共有します。これが皆さんのお役に立てば幸いです。 
フロントエンド (vue) マスタリーコースへのエントリー: ラーニングに入る
新しい機能がリリースされるにつれて、 Web appsますます大きくなります。企業のDevOps の取り組みでは、この種のリリース変更が毎日発生します。 【おすすめ関連チュートリアル：「angularチュートリアル」】
このようにリリース サイクルが速いと、コードはすぐに扱いにくくなる可能性があります。特に NextJS や Angular などのJavaScriptに基づいて開発されたプロジェクト。
ここでは、読みやすさ、保守性、拡張性を最大限に高めるためにAngularプロジェクトを管理するための 5 つのベスト プラクティスを紹介します。
多くの単一アプリケーション コアは、肥大化したクラスを含むコード ベースです。その性質上、これらの肥大化したプログラムを維持するのは困難です。コードを 1 行変更すると、プログラム全体に壊滅的な影響を与える可能性があるという意味で、脆弱です。単一責任の原則により、これらの問題を防ぐことができます。
単一責任の原則は、コンポーネントの機能が 1 つだけであることを意味します。
このアプローチを使用してアプリケーションを構築すると、アプリケーションがこれらのコード ブロックを通じて結び付けられたモジュール式フレームワークが作成されます。
このアプローチを使用すると、プログラムをより読みやすく、保守しやすくすることができます。また、アプリケーション内の指定された機能を簡単に見つけることもできます。
コードがこの要件を満たしていることを確認するには、次の質問を自問してください。这代码是干什么的？回答にandキーワードが含まれている場合は、コードを単一責任コードにリファクタリングする必要があります。
Angularアプリケーションの構築と拡張は継続的な作業です。単一責任の原則を使用してプロジェクトを整理すると、時間が経つにつれて、アプリケーションがクリーンになり、読みやすく、保守しやすくなります。
Angularのモジュールは、単一の原則の実装です。 Angularでは、各モジュールは個別の独立した機能を表します。
Angularタイプ モジュールを論理的にグループ化または編成する方法を指定するためのいくつかのタイプ モジュールが用意されています。
コア
Coreモジュールは、アプリケーションをインスタンス化し、グローバルに使用するコア関数をロードするために使用されるNgModuleです。
したがって、シングルトン サービスはコア モジュールに実装する必要があります。ヘッダー、フッター、またはナビゲーション バーは、このタイプのモジュールです。
アプリケーションごとにインスタンスが 1 つだけあるすべてのサービス (シングルトン サービス) は、コア モジュールに実装する必要があります。たとえば、認証サービスやユーザー サービスなどです。
特徴
汎用モジュールは、アプリケーション機能を構築するコードを表します。たとえば、オンライン ショッピング アプリケーションには、ショッピング カートに商品を追加する機能と、支払い用の別のモジュールがあります。
共有
共有モジュールは、組み合わせて新しい機能を作成できるモジュールで構成されます。たとえば、検索機能はプラットフォーム内の複数の機能に使用できます。
このようにコードを構造化すると、内容が見つけやすくなり、コードの再利用可能性が高まります。
スタイル ファイルは、共通の構造に従っていない場合、すぐに整理されなくなる可能性があります。一般的なベスト プラクティス パターン7-1パターン。以下に示すように、 7フォルダーと1ファイルを使用します。
アプリ- プロジェクトのメインフォルダー
抽象- すべての変数、ミックスイン、および同様のコンポーネントを含む抽象セクション
コア- サイト全体のレイアウト、リセット、定型コードが含まれています
コンポーネント- ボタン、タブ、モーダルなど、Web サイト用に作成されるすべてのコンポーネントのスタイルが含まれます。
レイアウト- ヘッダーやフッターなど、サイトのレイアウトを定義するために必要なファイルが含まれています
ページ- 特定のページごとのスタイルが含まれています
ベンダー- このオプションのフォルダーは、 bootstrapなど、プロジェクトで使用されるブートストラップ フレームワークに適しています。
各フォルダーに、その特定のフォルダーに対するすべての割り当てを含む新しいall.scssファイルを作成します。
多くのサービスはグローバルに実行されるように設計されています。さらに、場合によっては、コンポーネントにサービスが必要になります。従来のコーディング コンポーネントの実践では、単一責任の原則が推奨されています。
このアプローチでは、サービスとコンポーネントは別のプロジェクトとして記述されます。
しかし、これらのサービスのコンポーネントを削除することを検討するとどうなるでしょうか?最終的にはデッドコードとなり、倉庫がさらに乱雑になるだけです。この場合、ベスト プラクティスは、サービスをコンポーネント内に配置することです。
これにより、コンポーネントとサービスの保守が容易になります。
ネストされたファイル構造は、すべてのコード ファイルを 1 つのディレクトリに置くフラット ファイル システムよりも本質的にナビゲートが簡単です。
ただし、プロジェクトが近づくにつれて、プロジェクトのファイル構造は非常に複雑になる可能性があります。これによりコードの検索が容易になりますが、インポート ステートメントを作成する際に課題が生じます。
ディレクトリ構造が 3 レベルまたは 4 レベルを超えて大きくなり始めると、 importステートメントが非常に長くなり、読みにくくなる可能性があります。
この問題を解決するには、tsconfig.json ファイルでパスのエイリアスを構成します。このファイルには、 compilerOptionsという名前の配列があります。これは、アプリケーションで設定するパス エイリアスです。
コードがコンパイルされると、この配列で定義されたパス エイリアスは実際のパスに置き換えられます。各パスの値は、実際のパスとエイリアスを含むキーと値のオブジェクトです。
Angularアプリケーションの構築と拡張は継続的な作業です。