Multiple properties or single observer in Ember.Object

Question

If I have a series of properties that rely on the same property, what is the best (maintainable, fastest, etc) way of defining them? I can think of a few:

A. Property for each:

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. Observer that sets props all at once:

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. Straight-up computed props:

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) definitely seems the most elegant, but I'm wondering: are there are any penalties for using three computed properties versus one observer? And is (C) is basically shorthand for A? Any difference there?

Answer 1

C is a shorthand (although a small redirection) for A. And while B may give you the same answer as A and C now, it's not always guaranteed to do that. I would avoid B at all costs since it's very hard to tell where values are coming from. Use C if your team is comfortable with the shorthand, use A to be more explicit.

But most importantly, do not worry about speed, worry about readability. Something like this is probably the last thing you should check for performance.

Also, I'm not sure if this question is acceptable for the SO rules, but I thought I'd answer anyway.

EDIT: In regards to B not guaranteed to provide the same functionality, there's 2 parts to that.

1. Observers are synchronous now, but may not always be. Minimally you should use observesImmediately().
2. Observers are always active, even if the properties aren't used. If you use computed properties instead, Ember makes intelligent decisions about when and when not to update them.