1

同じプロパティに依存する一連のプロパティがある場合、それらを定義する最良の (保守可能、最速など) 方法は何ですか? 私はいくつか考えることができます：

A. それぞれのプロパティ:

isDraft: (->
  @get('status') is App.Status.DRAFT
).property('status')

isPublished: (->
  @get('status') is App.Status.PUBLISHED
).property('status')

isArchived: (->
  @get('status') is App.Status.ARCHIVED
).property('status')

B. 一度にすべての小道具を設定するオブザーバー:

isDraft: true
isPublished: false
isArchived: false

statusDidChange: (->
  @setProperties(
    isDraft: @get('status') is App.Status.DRAFT
    isPublished: @get('status') is App.Status.PUBLISHED
    isArchived: @get('status') is App.Status.ARCHIVED
  )
).observes('status')

C. ストレートアップの計算された小道具:

isDraft:     Ember.computed.equal('status', App.Status.DRAFT)
isPublished: Ember.computed.equal('status', App.Status.PUBLISHED)
isArchived:  Ember.computed.equal('status', App.Status.ARCHIVED)

(C) 間違いなく最も洗練されているように見えますが、1 つのオブザーバーに対して 3 つの計算されたプロパティを使用する場合に何らかのペナルティがあるのではないかと考えています。そして、(C) は基本的に A の省略形ですか? そこに違いはありますか？

4

1 に答える 1

2

C は A の短縮形です (リダイレクトは小さいですが)。現在、B は A や C と同じ答えを返すかもしれませんが、常にそうするとは限りません。値がどこから来ているのかを判断するのは非常に難しいため、B は絶対に避けます。チームが短縮形に慣れている場合は C を使用し、より明確に表現するには A を使用します。

しかし、最も重要なことは、速度について心配するのではなく、読みやすさについて心配することです。このようなものは、おそらくパフォーマンスをチェックする最後のことです。

また、この質問が SO ルールで受け入れられるかどうかはわかりませんが、とにかく答えると思いました。

EDIT：同じ機能を提供することが保証されていないBに関しては、2つの部分があります。

  1. オブザーバーは現在同期していますが、常にそうであるとは限りません。最低限使用する必要がありますobservesImmediately()。
  2. プロパティが使用されていない場合でも、オブザーバーは常にアクティブです。代わりに計算されたプロパティを使用すると、Ember はいつ更新するか、いつ更新しないかについてインテリジェントな決定を下します。
于 2014-10-30T20:44:37.867 に答える