高品質の角度1.5コンポーネントの構築ガイド

キーポイント

• コンポーネントの分離：結合を最小限に抑え、カプセル化を強化し、内部ロジックプライベートを維持し、他のコンポーネントとの相互作用を制御します。
• コンポーネントフォーカス：各コンポーネントは単一の責任に焦点を当て、それにより、単純さを維持しながら、テスト可能性と再利用性を改善します。
• 一元配置バインディング：消化サイクルの負荷を減らし、外部干渉なしにデータの流れを確実にし、パフォーマンスと設計の明確さを改善します。
• 単一の結合：ダイジェストサイクルのオブザーバーの数を減らすことにより、パフォーマンスをさらに最適化します。これは、静的または不変のデータに特に役立ちます。
• ライフサイクルイベント：$onInitや$onDestroyなどのライフサイクルイベントを使用して、コンポーネントの設定と分解を効果的に管理して、リソースが適切に初期化およびクリーニングされるようにします。
• コンポーネントイベント：コンポーネントは、Angular 2プラクティスに沿ったカスタムイベントと対話することを好む、他のコンポーネントと通信するためにイベントを発行する必要があります。 $scope

この記事は、マーク・ブラウンとユルゲン・ヴァン・デ・モエールによってレビューされました。 SetePointのすべてのピアレビューアーズに感謝します。

---

2017年1月10日：記事は更新され、一方向の結合に関するセクションを明確にし、1回のバインディングに関する情報を追加しました。 ---

Angular 1では、コンポーネントはカスタムHTML要素を作成するためのメカニズムです。これは過去にAngular Directivesを使用して可能でしたが、コンポーネントは、Angularのさまざまな改善に基づいて構築され、構築と設計のベストプラクティスを実施しました。

この記事では、コンポーネントの設計と、アプリケーションでそれらを使用する方法に飛び込みます。 Angular 1でコンポーネントの使用を開始していない場合は、最近のチュートリアルの構文と設計に関するチュートリアルを読むことができます。私の目標は、アプリケーションの品質を向上させるいくつかのベストプラクティスを概説することです。

また、Angular 2の多くのベストプラクティスが新しいコンポーネントAPIを介してAngular 1に導入されているため、後で簡単にリファクタリングできるアプリケーションを構築できることにも注意する必要があります。 Angular 2は、Angular 1コンポーネントについて考える方法と設計方法に影響しますが、まだ多くの明らかな違いがあります。 Angular 1はまだアプリケーションを構築するための非常に強力なツールであるため、Angular 2に移行する準備ができていなくても、アプリケーションを改善するためにコンポーネントを使用することに投資する価値があると思います。

良いコンポーネントは何ですか？

コンポーネントは、アプリケーションの強力なビルディングブロックにするために、多くの重要な機能を念頭に置いて設計する必要があります。各機能をさらに詳しく調べますが、コンポーネントが従うべき主な概念を以下に示します。

• 分離：コンポーネントのロジックをカプセル化し、内部およびプライベートに保つ必要があります。これにより、コンポーネント間の結合が減少します。
• フォーカス：コンポーネントは単一のユニットとして主要なタスクを実行する必要があります。これにより、理解しやすく、しばしば再利用しやすくなります。
• 一元配置結合：可能な場合は一方向の結合を使用して、ダイジェストサイクルの負荷を減らします。
• ライフサイクルイベントの使用：コンポーネントのライフサイクルはインスタンス化から始まり、ページからの削除で終わります。これらのイベントを使用してコンポーネントを維持するのが最善です。
• 不明なAPI：コンポーネントは、構成を一貫した方法で属性として受け入れる必要があります。そうすれば、使用方法を理解しやすくなります。
• 問題イベント：他のコンポーネントと通信するには、適切な名前とデータでイベントを発行する必要があります。

最初に、アプリケーションの残りの部分からコンポーネントを分離し、カプセル化する理由と方法を理解しましょう。

コンポーネントは分離する必要があります

Angular 1機能の進化は、正当な理由で孤立したカプセル化されたコンポーネントを有効にすることです。いくつかの初期のアプリケーションは、$scopeおよびネストされたコントローラーの使用と高度に結合されていました。最初はAngularは解決策を提供しませんでしたが、今ではそれがあります。

優れたコンポーネントは、内部ロジックを公開しません。これは、設計方法のために簡単に実現できます。ただし、絶対に必要な場合（たとえば、送信/ブロードキャストイベント）、コンポーネントの使用の悪用は避けるべきです。 $scope

コンポーネントは

に焦点を合わせる必要があります

コンポーネントは単一の役割を想定する必要があります。これは、テスト可能性、再利用性、シンプルさにとって非常に重要です。個々のコンポーネントを過負荷にする代わりに、追加のコンポーネントを作成することをお勧めします。これは、大きくて複雑なコンポーネントがないことを意味するものではなく、各コンポーネントが主要な作業に焦点を合わせる必要があることを意味します。

コンポーネントをアプリケーションでの役割に基づいて、コンポーネントを4つの主要なグループに分割して、コンポーネントの設計方法を考えるのに役立ちます。これらの異なるタイプのコンポーネントを構築するための違いはありません。コンポーネントが想定する特定の役割を考慮してください。

これらのタイプは、Angularを使用した私の5年以上の経験に基づいています。わずかに異なる方法で整理することを選択できますが、基本的な概念は、コンポーネントが明確な役割を果たしていることを確認することです。

アプリケーションコンポーネント

アプリケーションのルートとして機能できるアプリケーションコンポーネントは1つだけです。 Webアプリケーションの本文に1つのコンポーネントしかないことを考えることができます。

<code>>
  <app>></app>>
>
</code>

これは、Angular 2の設計の一貫性に主に推奨されるため、移行したい場合は将来的に簡単になります。また、アプリケーションのすべてのルートコンテンツを単一のコンポーネントに移動することでテストに役立ちます（その一部をindex.htmlファイルに配置するのではなく）。アプリケーションコンポーネントはまた、アプリケーションをインスタンス化する場所を提供するため、アプリケーション実行方法でこれを行う必要はありません。

$rootScopeこのコンポーネントは、できるだけ単純でなければなりません。可能であれば、バインディングやコントローラーなしで、テンプレートのみを含める場合があります。ただし、

を置き換えたり、アプリケーションのニーズを起動したりしません。

ルーティングコンポーネント

過去には、UIルーター状態（またはngrouteルーティング）にコントローラーとテンプレートをリンクしました。ルートをコンポーネントに直接リンクできるようになるため、コンポーネントはまだコントローラーとテンプレートのペアがありますが、ルーティング可能な利点もあります。

たとえば、

UIルーターを使用して、テンプレートとコントローラーをリンクする方法です。

<code>>
  <app>></app>>
>
</code>

URLをコンポーネントに直接リンクできるようになりました。

<code>$stateProvider.state('mystate', {
  url: '/',
  templateUrl: 'views/mystate.html',
  controller: MyStateController
});
</code>

これらのコンポーネントは、プロジェクトIDなどのルーティングパラメーターからのデータをバインドでき、その役割は、必要な他のコンポーネントをロードするためのルーティングの設定に焦点を当てることです。ルーティング定義へのこのように一見マイナーな変更は、Angular 2の移動機能にとって実際には非常に重要ですが、Angular 1.5では、コンポーネントレベルでテンプレートとコントローラーをより適切にカプセル化するため、同様に重要です。

Angular 1には、実際にはNgrouteとNgComponentrouterの2つのルーティングモジュールがあります。 NGComponentrouterのみがコンポーネントをサポートしていますが、それも非推奨です。最良の方法は、UIルーターを使用することだと思います。

状態コンポーネント

アプリケーション用に構築する唯一のコンポーネントのほとんどは、ステートフルです。ここでは、実際にアプリケーションビジネスロジック、HTTPリクエスト、プロセスフォーム、およびその他のステートフルなタスクを発行します。これらのコンポーネントはアプリケーションに固有のものである可能性があり、視覚的なレンダリングではなくデータの維持に焦点を当てています。

ディスプレイ用のユーザープロファイルデータをロードするコントローラーがあり、ディレクティブにリンクされている対応するテンプレート（ここには表示されていない）もあるとします。このコードスニペットは、おそらく仕事をするための最も基本的なコントローラーです。

<code>$stateProvider.state('mystate', {
  url: '/',
  component: 'mystate'
});
</code>

コンポーネントを使用して、以前よりもうまく設計できます。理想的には、コントローラーで直接$httpを使用する代わりに、サービスを使用する必要があります。

<code>.controller('ProfileCtrl', function ($scope, $http) {
  $http.get('/api/profile').then(function (data) {
    $scope.profile = data;
  });
})
.directive('profile', function() {
  return {
    templateUrl: 'views/profile.html',
    controller: 'ProfileCtrl'
  }
})
</code>

これで、独自のデータをロードするコンポーネントがあるため、ステートフルになります。これらのタイプのコンポーネントは、単一のルートにリンクするために使用できないことを除いて、ルーティングコンポーネントに似ています。

ステートフルコンポーネントは、他の（ステートレス）コンポーネントを使用して実際にUIをレンダリングします。また、データアクセスロジックをコントローラーに直接配置する代わりに、サービスを使用する必要があります。

ステートレスコンポーネント

ステートレスコンポーネントは、ビジネスロジックを管理せずにレンダリングに焦点を当てており、特定のアプリケーションに固有の必要はありません。たとえば、フォームコントロール、カードなどのUI要素に使用されるほとんどのコンポーネントは、データの読み込みや保存フォームなどのロジックも処理しません。それらは、高度にモジュール化され、再利用可能で、孤立しているように設計されています。

ステートレスコンポーネントがデータまたはコントロールテンプレート内のすべてのみを表示する場合、コントローラーは必要ない場合があります。ステートフルコンポーネントからの入力を受け入れます。この例は、ステートフルコンポーネント（上記のプロファイルの例）から値を取得し、アバターを表示します。

<code>.component('profile', {
  templateUrl: 'views/profile.html',
  controller: function($http) {
    var vm = this;
    // 当组件准备好时调用，见下文
    vm.$onInit = function() {
      $http.get('/api/profile').then(function (data) {
        vm.profile = data;
      });
    };
  }
})
</code>

それを使用するために、ステートフルコンポーネントは、以下に示すように、属性にユーザー名を渡します：<avatar username="vm.profile.username">.</avatar>

使用するライブラリの多くは、ステートレスコンポーネント（および可能なサービス）のコレクションです。彼らは確かに彼らの動作を変更するための構成を受け入れることができますが、彼らは自分の外側の論理に責任を負うことを意図していません。

コンポーネントは一元配置バインディング

を使用する必要があります

これはコンポーネントにとって新しいものではありませんが、通常、コンポーネントで使用するのが賢明です。一方向の結合の目的は、アプリケーションのパフォーマンスの主要な要因であるダイジェストサイクルへのより多くの作業を積み込むことを避けることです。データは、外を見ることなくコンポーネントに流れ込んで（今日存在するいくつかの結合の問題につながります）、コンポーネントはその入力に基づいて単純にそれ自体をレンダリングできます。この設計は、Angular 2でも動作します。これは、将来の移行に役立ちます。

この例では、タイトル属性は、指定された初期値に基づいてコンポーネントに1回だけバインドされます。タイトルが外部アクターによって変更された場合、コンポーネントに反映されません。結合が一方向であることを示す構文は、

を使用することです

<code>>
  <app>></app>>
>
</code>

タイトルプロパティが変更された場合、コンポーネントはまだ更新されます。可能な限り一元配置バインディングを使用することをお勧めします。

コンポーネントは、単一のバインディング

を考慮する必要があります

Angularには、1回でデータをバインドする機能もあるため、ダイジェストサイクルを最適化できます。基本的に、Angularは最初の非未定された値をバインディングに提供し、その値に結合し、（すべてのバインディングが解析されたら）関連する観測者を消化サイクルから除去します。これは、特定のバインディングが将来のダイジェストループに処理時間を追加しないことを意味します。

これは、

で結合式の前に行われることによって行われます。ライフサイクル中に入力結合が変わらないことがわかっている場合、そうすることは理にかなっています。この例では、タイトルが一方向のバインディングである場合、コンポーネント内で更新され続けますが、ここでのバインディングは、1回のバインディングとして指定するため、更新されません。 ::

<code>$stateProvider.state('mystate', {
  url: '/',
  templateUrl: 'views/mystate.html',
  controller: MyStateController
});
</code>

コンポーネントはライフサイクルイベントを使用する必要があります

新しい関数として

関数に気づいたかもしれません。コンポーネントには、コンポーネントの特定の側面を管理するために使用する必要があるライフサイクルと対応するイベントがあります。 $onInit

$onInit()

コンポーネントライフサイクルの最初のステップは初期化です。このイベントは、コントローラーとバインディングが初期化された後に実行されます。ほとんどの場合、この方法をコンポーネントのセットアップまたは初期化に使用する必要があります。実行する前に、すべての値がコンポーネントで利用可能になることを保証します。コントローラーにバウンド値に直接アクセスすると、これらの値が利用可能であることを保証することはできません。

<code>$stateProvider.state('mystate', {
  url: '/',
  component: 'mystate'
});
</code>

$postLink()

次のステップは、テンプレート内の子要素をリンクすることです。コンポーネントが初期化された場合、テンプレートで使用される子要素をレンダリングしたという保証はありません。これは、DOMを何らかの形で操作する必要がある場合に重要です。重要な警告は、イベントがトリガーされたときに非同期にロードされたテンプレートがロードされていない可能性があるということです。テンプレートキャッシュソリューションをいつでも使用して、テンプレートが常に利用可能であることを確認できます。

<code>>
  <app>></app>>
>
</code>

$onChanges()

コンポーネントがアクティブな場合、入力値の変化に反応する必要がある場合があります。一方向のバインディングはまだコンポーネントを更新しますが、入力が変更されたときにリッスンする新しい$onChangesイベントバインディングがあります。

この例では、コンポーネントに製品のタイトルと説明が提供されていると仮定します。以下に示すように、変更を検出できます。現在の値と以前の値を含む、利用可能なバインディングにマッピングされたオブジェクトを持つ関数に渡されたオブジェクトを表示できます。

<code>$stateProvider.state('mystate', {
  url: '/',
  templateUrl: 'views/mystate.html',
  controller: MyStateController
});
</code>

$onDestroy()

最終段階は、ページからコンポーネントを削除することです。このイベントは、コントローラーとそのスコープが破壊される前に実行されます。イベントリスナー、オブザーバー、またはその他のDOM要素など、コンポーネントがメモリを作成または保持する可能性のあるものをクリーンアップすることが重要です。

<code>$stateProvider.state('mystate', {
  url: '/',
  component: 'mystate'
});
</code>

コンポーネントには明確なapi

が必要です

データセットでコンポーネントを構成して初期化するには、コンポーネントがこれらの値を受け入れるためにバインディングを使用する必要があります。これは、コンポーネントAPIと見なされる場合があります。これは、コンポーネントが入力を受け入れる方法を説明する別の方法です。

ここでの課題は、バインディングに簡潔ではあるが明確な名前を提供することです。開発者は、名前を短くして非常に簡潔にしようとすることがありますが、これはコンポーネントの使用には危険です。ストックコードを入力として受け入れるコンポーネントがあるとしますが、次のうちどれが優れているのでしょうか。

<code>.controller('ProfileCtrl', function ($scope, $http) {
  $http.get('/api/profile').then(function (data) {
    $scope.profile = data;
  });
})
.directive('profile', function() {
  return {
    templateUrl: 'views/profile.html',
    controller: 'ProfileCtrl'
  }
})
</code>

symbolが良いと思うことを願っています。開発者は、名前の競合を避ける方法として、コンポーネントとバインディングをプレフィックスすることも好きな場合があります。たとえば、md-toolbarは材料ツールバーですが、すべてのバインディングのプレフィックスが冗長になり、避ける必要があります。

コンポーネントはイベントを発行する必要があります

他のコンポーネントと通信するには、コンポーネントがカスタムイベントを発行する必要があります。コンポーネント間の数を同期するために、サービスを使用して双方向のデータバインディングの多くの例があります

そうですが、イベントはより良いデザインの選択です。イベントは、ページと通信する方法としてはるかに効率的です（そして、JavaScript言語の基本的な部分であり、Angular 2ではどのように機能するか、偶然ではありません）。

（スコープツリーまで）または

（スコープツリーまで）で使用できます。これは、クイックサンプルイベントの実用的なアプリケーションです。 $emit $broadcast

コンポーネント間で通信する必要がある2つの主な状況があります。知っているコンポーネント間と、わからないコンポーネント間です。この違いを説明するために、ページ上のタブを管理するのに役立つコンポーネントのセットと、対応するヘルプページリンクを備えたツールバーがあると仮定しましょう。

<code>.component('profile', {
  templateUrl: 'views/profile.html',
  controller: function($http) {
    var vm = this;
    // 当组件准备好时调用，见下文
    vm.$onInit = function() {
      $http.get('/api/profile').then(function (data) {
        vm.profile = data;
      });
    };
  }
})
</code>

この場合、

<code>.component('avatar', {
  template: '<img  src="/static/imghw/default1.png" data-src="https://img.php.cn/upload/article/000/000/000/173975605585460.png" class="lazy" ng- alt="高品質の角度1.5コンポーネントの構築ガイド" >',
  bindings: {
    username: '  },
  controllerAs: 'vm'
})
</code>

および

コンポーネントは、3つの異なるタブのセットを作成するために協力しているため、お互いを知っている可能性があります。ただし、コンポーネントは認知範囲を超えています。 my-tabs

別のタブが選択されている場合（これはmy-tabコンポーネントインスタンスでのイベントになります）、my-tabsコンポーネントは、インスタンスを表示するためにタブの表示を調整できるように知る必要があります。 my-tabコンポーネントは、イベントを親my-tabsコンポーネントまで上向きに発行できます。このタイプの通信は、単一の関数（タブ付きインターフェイス）を作成するために連携する2つのコンポーネント間の内部通信のようなものです。

しかし、my-toolbar目に見えるコンテンツに基づいてヘルプボタンを変更できるように、現在選択されているタブを知りたい場合はどうなりますか？ my-tabイベントは、親ではないため、my-toolbarに到達することはありません。したがって、別のオプションは、$rootScopeを使用してコンポーネントツリー全体のイベントを発行することです。これにより、コンポーネントが聞くことができます。ここでの潜在的な欠点は、イベントが各コントローラーに到達するようになり、別のコンポーネントが同じイベント名を使用する場合、予期しない効果をトリガーする可能性があることです。

ユースケースに適したアプローチを決定しますが、別のコンポーネントがイベントについて知る必要がある場合はいつでも、2番目のオプションを使用してコンポーネントツリー全体にイベントを発行することをお勧めします。

要約

Angular 1アプリケーションは、コンポーネントを使用して作成できるようになりました。これにより、アプリケーションライティングのベストプラクティスと性質が変更されます。これはより良いものですが、コンポーネントを使用するだけで、以前よりも必ずしも優れているわけではありません。 Angular 1コンポーネントを構築するときは、次のポイントに留意してください。

• ロジックを分離します。一貫性と品質を確保するために、アプリケーションの他の側面から、可能な限り内部および内部的に離れてコンポーネントロジックを保持します。
• コンポーネントをシンプルに保ち、単一の役割に焦点を合わせます。それらは複雑なコンポーネントである可能性がありますが、単一のコンポーネントのさまざまなタスクをユニットとして論理的に接続する必要があります。
• ライフサイクルイベントを使用します。コンポーネントライフサイクルに接続することにより、データが適切なタイミングで準備ができていること、そしてそれをクリーンアップできることを確認できます。
• 一元配置とシングルショットのバインディングを使用します。可能であれば、一方向の結合はより効率的であり、優れた設計を促進しますが、シングルタイムのバインディングはアプリケーションをスピードアップできます。いつでも$onChangesライフサイクルイベントを使用して、変化を観察できます。
• イベントを使用して通信します。コンポーネントは、Angular 2の機能と一致するカスタムイベントを使用して通信できます。
• 明確なAPIがあります。コンポーネントが明確かつ簡単に理解できる名前を確認してください。

Angular 1.xアプリケーションでコンポーネントを使用していますか？または、Angular 2に切り替えるまで待つつもりですか？以下のコメントであなたの経験について聞いてみたいです。

角度1.5コンポーネントの構築に関するFAQ

Angular 1.5コンポーネントとディレクティブの主な違いは何ですか？

Angular 1.5コンポーネントは、ディレクティブを作成するためのよりシンプルで直感的なAPIです。指示は強力ですが、柔軟性のために使用するのが難しい場合があります。一方、コンポーネントはよりシンプルな構成を備えており、UI要素を構築するために使用するように設計されています。また、一元配置データのバインディングとライフサイクルフックの使用を促進し、より予測可能なデータフローとデバッグが簡単につながる可能性があります。

Angular 1.5コンポーネントで一元配置データバインディングを使用する方法は？

Angular 1.5コンポーネントの

属性を使用して、一元配置データバインディングを実現できます。 bindings

ライフサイクルフックとは何ですか？ Angular 1.5コンポーネントでそれらを使用する方法は？

ライフサイクルフックは、コンポーネントのライフサイクルの特定のポイントで呼び出される関数です。 Angular 1.5では、

、$onInit、$onChanges、$onDestroyなどのいくつかのライフサイクルフックが導入されます。これらのフックは、データの初期化、リソースのクリーンアップ、バインディングの変更に反応するなどのタスクを実行するために使用できます。 $postLink

Angular 1.5のコンポーネント間で通信する方法は？

コンポーネント間の通信は、Angular 1.5のバインディングとイベントを使用して実現できます。親から息子のコミュニケーションは拘束力を使用して行うことができますが、子どもから親のコミュニケーションはイベントを使用して行うことができます。これにより、一方向のデータフローが容易になり、アプリケーションが理解しやすくなります。

Angular 1.5の指令からコンポーネントに移行する方法は？

Angular 1.5の指令からコンポーネントへの移行には、いくつかのステップが含まれます。まず、オブジェクトをコンポーネント定義に定義する指令を置き換えます。次に、リンク関数をライフサイクルフックに置き換えます。最後に、双方向のデータ結合を一方向のデータバインディングおよびイベントに置き換えます。

ディレクティブの代わりにAngular 1.5でコンポーネントを使用することの利点は何ですか？

Angular 1.5のコンポーネントは、指示よりもいくつかの利点を提供します。一元配置データバインディングと一元配置データフローを容易にし、ライフサイクルフックを提供するよりシンプルなAPIがあります。これらの機能により、コードが理解し、デバッグし、維持されやすくなります。

Angular 1.5コンポーネントで転写を使用する方法は？

コンポーネント定義の

オプションを使用して、角度1.5コンポーネントで転写を達成できます。これにより、コンポーネントのテンプレートにカスタムコンテンツを挿入できます。これは、再利用可能なUI要素を作成するのに非常に役立ちます。

Angular 1.5コンポーネントでマルチスロット転写を作成する方法は？ transclude

マルチスロット転写は、オブジェクト構文を使用して

オプションを使用して、Angular 1.5コンポーネントに実装できます。これにより、カスタムコンテンツで満たすことができるコンポーネントのテンプレート内の複数の転写スロットを定義できます。

Angular 1.5コンポーネントでLifecycleフックを使用する方法は？ transclude 一方向バインディングが更新されるたびに、Angular 1.5コンポーネントのライフサイクルフックが呼び出されます。バインディングの電流値と以前の値を含む変更オブジェクトを受信します。これを使用して、バインディングの変更に対応し、コンポーネント状態の更新やデータの取得などのタスクを実行できます。

Angular 1.5コンポーネントでLifecycleフックを使用する方法は？ $onChanges

コンポーネントの要素とその子要素がリンクされた後、Angular 1.5コンポーネントのライフサイクルフックが呼び出されます。これは、イベントリスナーのセットアップやDOMの操作など、コンポーネントのDOM要素へのアクセスを必要とするタスクを実行するために使用できます。

以上が高品質の角度1.5コンポーネントの構築ガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。