Ember.jsのビューとコンポーネント


143

私はember.jsを学習していますが、ビューとコンポーネントの違いを理解しようとしています。どちらも、再利用可能なコンポーネントを作成する方法と考えています。

エンバーのウェブサイトからの見解:

Ember.jsのビューは通常、次の理由でのみ作成され
ます
。- ユーザーイベントの高度な処理が必要な場合- 再利用可能なコンポーネントを作成する場合

コンポーネントに関するEmberのWebサイトから:

コンポーネントは、JavaScriptを使用して動作を実装し、ハンドルバーテンプレートを使用して外観を記述するカスタムHTMLタグです。アプリケーションのテンプレートを簡略化できる再利用可能なコントロールを作成できます。

では、ビューとコンポーネントの主な違いは何ですか?また、コンポーネントよりもビューを使用したい、またはその逆の一般的な例は何ですか?

回答:


170

Ember.View

アンEmber.Viewは現在、W3Cによって自動的に作成されたタグに限定されています。しかし、独自のアプリケーション固有のHTMLタグを定義し、JavaScriptを使用してそれらの動作を実装したい場合はどうでしょうか。Ember.Viewでは実際にこれを行うことはできません。

Ember.Component

それこそが、コンポーネントで実現できることです。実際、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の公開により、ほとんどの場合、ビューの代わりにコンポーネントを使用することが推奨されます。


1
コンポーネントに関する私の唯一の懸念は、コンポーネントが複雑になるときです。ロジック部分をレンダリング部分から分離する方法はまだわかりません。私は通常の見解ですが、この分離があり、ロジックをコントローラーに入れることができますが、コンポーネントを使用すると、非常に複雑な、おそらく巨大な混乱が発生することになります。コンポーネント専用のコントローラーのようなものを定義できるかどうか知っていますか?あるいは、コンポーネントは単に複雑なグラフィック要素を管理することを目的としていないのかもしれません。
sly7_7 2013

3
@ sly7_7、はい、私はあなたの要点を理解します。しかし、私はコンポーネントをブラックボックスと見なし、渡されたデータにのみ基づいて動作します。そして、はい、それが何をするかによっては、これがすぐに混乱する可能性があります。専用コントローラーは絶対的な意味があり、コンポーネントがロジックに注入されるようになった場合に機能しますが、コンポーネントが仕様上、エンバーのコンテナーの一部ではないことはわかっていますが、将来的には変更される可能性がありますこのようなものを正確に解決します。とにかくポイント!
直感的な

2
バインディングはコンポーネントから出ることができますか?IE、コンポーネントのブロックフォームを使用すると、ブロック内のコンテンツ要素をコンポーネントのプロパティにバインドできますか。この場合、ビューを使用する必要がありますか?
Michael Johnston、

2
ああ、そうです。{{view.xxxx}}コンポーネントはビューと同じように機能します。
Michael Johnston、

このトピックのトムデールのコメント:ember.zone/the-confusion-around-ember-views-and-components/...
Akshay Rawat

17

答えは簡単です:コンポーネントを使用する

2013年8月に記録されたトレーニングビデオによると、Yehuda KatsとTom Dale(Ember Coreチームメンバー)は、フレームワーク開発者でない限り、ビューを使用しないようオーディエンスに指示しました。それらはハンドルバーと導入されたコンポーネントに多くの拡張を加えたので、ビューはもはや必要ありません。ビューは、{{#if}}や{{outlet}}などを強化するために内部的に使用されます。

コンポーネントはまた、ブラウザーに組み込まれるWebコンポーネント標準を厳密に模倣しているため、Emberコンポーネントの作成を快適にすることには多くの副次的な利点があります。

アップデート2014-11-27

Ember 2.0は、ルートが入力されたときに、コントローラー/ビューの代わりにルーティング可能なコンポーネントを使用するため、ビューの代わりにコンポーネントを使用することがさらに重要になっています。アプリの将来性を保証するために、ビューを避けておくのが最善です。

出典:


5
「ビューを使用する必要があると思われる場合は、代わりにコンポーネントを使用してください。」ひどいアドバイスであり、コンポーネントに含まれる分離の理解の欠如を裏切る。
jmcd 14

@jmcd、そのコメントはフレームワーク開発者自身からのものでしたが、私はそれを取り出しました。
Johnny

2
ソースを見つけました:Gaslightビデオトレーニング、ビデオ10.3コンポーネントQ&A @ 26mマーク。トムは言う: ``これらの例が書かれて以来、...これらの例が書かれたときに存在しなかったコンポーネントを追加しました。一般的に、私は「彼らはこの時点で複数の内部簿記オブジェクトのだ、ビューは、我々はほとんどの開発者は書面であることを期待するものではないと言うだろう
jmcd

2
@jmcd、そのビデオ@ 26:15で、トムは「基本的にビューを使用しない」と言います。また、同じ動画で30mにジャンプすると、Yehuda Katz氏は次のように述べています。 Viewを使用するために作成したもので、Viewに最も近いがセマンティクスが優れているのはComponentです。以前にViewを使用できたものであれば、Componentで結構です。」
ジョニー・

5

現在のところv2.x、現在の安定版リリースであるため、ビューは完全に非推奨になりました。Ember 2.0 APIからビューが削除されていると言われています

したがって、{{view}}Ember 2.0でキーワードを使用すると、アサーションがトリガーされます。

アサーションが失敗しました:使用{{view}}またはそれに基づくパスはEmber 2.0で削除されました

Ember 2.0でビューを使用する必要がある場合は、バージョン2.4までEmberと互換性のあるember-legacy-viewsアドオンを使用できます。

つまり、まとめると、コンポーネントは現在(ビューは削除されます)であり、未来です。これらもコントローラーに置き換わります。ルーティング可能なコンポーネントRFCを参照してください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.