アンEmber.Viewは現在、W3Cによって自動的に作成されたタグに限定されています。しかし、独自のアプリケーション固有のHTMLタグを定義し、JavaScriptを使用してそれらの動作を実装したい場合はどうでしょうか。Ember.Viewでは実際にこれを行うことはできません。
それこそが、コンポーネントで実現できることです。実際、W3Cが現在カスタム要素仕様に取り組んでいることはとても良い考えです。
Emberのコンポーネントの実装は、できるだけWebコンポーネントの仕様に近づこうとします。いったんカスタム要素がブラウザで広く利用可能である、あなたは簡単にW3C標準にごエンバーコンポーネントを移行し、それらを新しい標準を採用しているだけでなく、他のフレームワークによって使用可能持つことができるはずです。
これは私たちにとって非常に重要であり、標準化団体と緊密に連携して、コンポーネントの実装がWebプラットフォームのロードマップに一致するようにしています。
また、Ember.Componentは実際にはEmber.View(サブクラス)ですが、完全に分離されていることにも注意してください。テンプレートのプロパティアクセスはビューオブジェクトに移動し、アクションはビューオブジェクトも対象とします。周囲context
または外部へのアクセスはありません。controller
すべてのコンテキスト情報がに渡されます。これは、実際に周囲のコントローラーにアクセスできるEmber.Viewの場合とは異なります。たとえば、ビュー内では、次のようなthis.get('controller')
ことができます。現在ビューに関連付けられているコントローラー。
では、ビューとコンポーネントの主な違いは何ですか?
したがって、コンポーネントで独自のタグを作成できること以外の主な違いは、カスタム要素が利用可能になる将来のある時点で、カスタム要素をサポートする他のフレームワークでそれらのコンポーネントを移行/使用することです。特定の実装ケースに応じて、ビューはやや時代遅れになります。
また、コンポーネントよりもビューを使用したい、またはその逆の一般的な例は何ですか?
上記に続くことは明らかにあなたのユースケースに依存します。しかし、経験則として、ビューで周囲のコントローラーなどにアクセスする必要がある場合はEmber.Viewを使用しますが、ビューを分離して、コンテキストに依存しないようにするために必要な情報のみを渡したい場合は、はるかに再利用可能な場合は、Ember.Componentを使用します。
それが役に立てば幸い。
更新
Road to Ember 2.0の公開により、ほとんどの場合、ビューの代わりにコンポーネントを使用することが推奨されます。