[RFC] Make computed.or return truthy object rather than true

[soulcutter]

The current behavior of Ember.computed.or will return true

I propose that it would be useful to instead return the truthy object, which more-closely matches the semantics of JavaScript ||. This could make computed.or more-useful for rendering templates (you seldom want to render true, but may want to render one of the ored objects).

Example use case:

export default DS.Model.extend({
  shortDescription: DS.attr('string'),
  verboseDescription: DS.attr('string'),
  description: Ember.computed.or('verboseDescription', 'shortDescription')
})

I can see this tripping people up who have written implementations depending on a computed.or property being === true. In other words it has potential to break apps depending on the existing behavior.

[stefanpenner]

i would also love this 👍 we should see if this has backwards compatible issues.

also, and should do the same

[tonycoco]

Would this be something that could get a PR quickly and move it forward? Extremely useful!

[stefanpenner]

likely yes

[soulcutter]

I have no problem putting a PR up for this, expect one tonight if nobody else gets to it first.

[stefanpenner]

I have no problem putting a PR up for this, expect one tonight if nobody else gets to it first.

👍

[ahacking]

How is this different from Ember.computed.any ?

[stefanpenner]

@ahacking it isn't, we should deprecate any, no reason to have both.

[ahacking]

@stefanpenner OK cool, I support deprecating Ember.computed. any and calling it Ember.computed.or.

When getting up to speed on Ember I first reached for Ember.computed. or on numerous occasions and only later discovering any after implementing my own CP to get the or semantics I wanted.

+1

[e00dan]

This week I came across this issue and even searched through API but couldn't find method that returns object instead of bool so I ended up writing:

application: Em.computed 'controllers.application', 'targetObject.controllers.application', ->
  @get('controllers.application') or @get('targetObject.controllers.application')

or:

controllerContext: Em.computed 'targetObject', ->
    @get('targetObject') or @

Btw. I still don't know how to reference this as Em.computed argument, next to 'targetObject'.

I've noticed .any because of @ahacking's comment.

[soulcutter]

Implementation-wise any is slightly different in that it returns null rather than false. Not sure that matters to anyone, but there you have it.

[soulcutter]

Thinking about this a little more, the null return value probably is important in template rendering. The way javascript || works is that it returns the last value, so

undefined || null // => null
null || undefined // => undefined
null || false // => false

It makes sense to me to do that in computed.or as well