6

チームメイトと私はこの 4 か月間、Aureliaでアプリケーションを構築してきました。彼と私は、この 2 つの異なる方法でコンポーネントを作成し、使用してきました。ある程度の一貫性を保ち、すべてを 2 つのスタイルのいずれかに変更したいのですが、どちらが優先され、ニーズにより適しているかわかりません。

私が使用する<compose>ことにしたのは、それがよりクリーンに感じられ、遭遇したすべてのニーズに合っているためですが、カスタム要素を使用する方が客観的に優れている場合は、それに切り替えたいと思います.

例えば：

（彼の方法のビューモデル:)

import { bindable, bindingMode } from 'aurelia-framework';

export class HisWay {
  @bindable({ defaultBindingMode: bindingMode.twoWay }) data;
}

（彼の方法のビュー:)

<require from="./his-way"></require>
<his-way data.two-way="myModel" containerless></project-name>

(私のやり方のビューモデル:)

export class MyWay {
  activate(model) {
    this.model = model;
  }
}

（私のやり方の見方:)

<compose view-model="./my-way" model.bind="myModel" containerless></compose>

変更する必要がありますか? そうでない場合、私が使用していたのと同じスタイルを使用するように彼を説得するために使用できるいくつかの理由は何ですか?

4

4 に答える 4

9

可能であれば、カスタム要素アプローチを使用してください。

Compose は動的シナリオをターゲットにします。<compose>要素viewと属性の値が静的 (データにバインドされていない) である場合view-model、以下に説明する理由により、おそらくカスタム要素を使用する必要がありました。

移植性:カスタム要素はカプセル化の度合いが高いため、移植性が高くなります。カスタム要素のテンプレートは外側のスコープにアクセスできません。すべてのデータは@bindableプロパティを介して渡す必要があります。<compose>これは、外側のスコープへのアクセスを許可するとは対照的です。

Features : カスタム要素には、要素よりも多くの機能があり<compose>ます。テンプレート パーツ/スロット (トランスクルージョン)、バインド可能なプロパティ、経由で「グローバル化」する機能globalResourcesなど。

再利用: ウィジェットをカスタム要素にカプセル化し、globalResources. チームは、有効な式<mega-widget ...></mega-widget>への相対パスを覚えて記述しなければならないのではなく、mega-widget.html単純に記述することができます。mega-widget.js<compose view="..." view-model="..."></compose>

適合性が高い: データ入力ウィジェットを作成するユースケースには、カスタム要素が必要です。<currency value.bind="unitCost"></currency>で同様の結果を達成しようとするよりも、通貨カスタム要素を使用する方がはるかに簡単<compose>です。あなたが本当にそれを達成する方法がわからない.

CSS : 特定の構成要素インスタンスよりも、CSS セレクターを使用してカスタム要素をターゲットにする方が簡単です。 mega-element { display: block; ... }

https://www.danyow.net/aurelia-custom-element-vs-compose/

于 2016-08-12T14:28:57.250 に答える
1

答えはノーだ。提供されている例のような状況では、切り替える必要はありません。Compose 要素 (コンポーネント) とカスタム要素は、さまざまな問題を解決します。前者を使用すると、ビューまたはビューとビューモデルのペアを別のビューに構成できます。デフォルトの動作は、名前に基づいてビューとビューモデルを一致させますが、実際には毎回異なるビューモデルをバインドできることを理解しています (これは、for ループなどで興味深い用途を提供する可能性があります)。より扱いやすいチャンクに。コードを再利用したい場合にも使用しますが、フッターやナビゲーションなど、ある用途から別の用途にカスタマイズすることはあまり考えていません。

私が理解しているカスタム要素は、基本的に WebComponents であり、Shadow DOM を利用する進化中の Web 標準です。(以下のリンクで詳細を読むことができます。) 似ていますが、それらは単純なコンポーネントよりもはるかに強力であり、IMO はより優れた再利用能力を備えています。コンポーネントとは異なり、カスタム要素はさまざまなバインドされた属性を持つことができるため、ビューで使用する際により細かく制御できます。あなたのチームメイトの例は、彼らを正当化するものではありません。そのような状況では、コンポーネントがより良い選択であると主張することができます。

于 2016-08-12T02:36:27.873 に答える
1

個人的には、特定のアプローチのみを使用するように強制するつもりはありません。ほとんどのフレームワークは、成功するパラダイムが 1 つしかないことを納得させようとするという事実に悩まされています。しかし、それは真実ではありません。プロジェクトごとに、またプロジェクト内であっても、各要件は完全に異なる可能性があるからです。

したがって、カスタム要素名を使用してコンポーネントをレンダリングするか、構成を使用するかを検討するときは、まず、達成したい設計目標は何かを自問してください。私の意見では、統一は十分ではありません。

カスタム要素のアプローチのみを使用することは、読みやすく、静的なページ構造に簡単に移行できるため、優れています。一方、ページに多くの動的な構成が必要な場合は、その名前が示すように、構成されたアプローチが適しています。

したがって、compose の方が優れている、またはより柔軟であると言うことに同意する傾向がありますが、同時にちょっと冗長でもあります。

Compose に対する反論の 1 つは、カスタム属性の使用です。たとえば、aurelia-i18n を使用していて、属性変換アプローチを使用したい場合は、カスタム要素構文を使用する方がよいでしょう。ご覧のとおり、ユースケースがすべてです。

編集：

本当に核心に行きたいのであれば、カスタム要素アプローチの最良の議論は、構成自体は実際にはカスタム要素にすぎないということです.

于 2016-08-11T13:55:23.720 に答える