Ember.computed.includes

[sandstrom]

The most common long-form computed property in our project are simple checks to see if some array contains a string.

Would you be open to adding this functionality as a computed property?

// wasteful
hasBanana: function() {
  return this.get('possessions').includes('banana');
}.property('possessions', 'banana'),

// wonderful
hasBanana: Ember.computed.includes('possessions', 'banana'),


// usage
let hamster = Hamster.create();

hamster.get('hasBanana'); // false

hamster.set('possessions', ['orange']);
hamster.get('hasBanana'); // false

hamster.set('possessions', ['banana']);
hamster.get('hasBanana'); // true

---

No RFC yet, just want to get initial reactions.

[cursedquail]

This would work great in an addon like ember-awesome-macros, but I don't think that it belongs in the core Ember.js

[cursedquail]

emberjs/ember.js#13831

Also this was brought up over a year ago, and wasn't accepted.

[sandstrom]

@NLincoln Yeah I know, I don't understand why though 😄

(obviously it's subjective, what should be included or not, so if few agree with me then it doesn't have it's place in core)

[workmanw]

I added an RFC for computed.sortBy and it had a more lengthy discussion about adding new computed properties in general. That might be relevant to providing some back story: #87

[sandstrom]

@workmanw Thanks, much appreciated! 😄

Got it, I'll just assume the moratorium stands and close this. While I don't agree it's not a biggie and the addon-route is a simple one.

[workmanw]

@sandstrom 👍 -- FWIW I too feel like everything on Ember.Enumerable should be a first party computed macro. Using an addon is easy, but not always initiative for new users.

[webark]

@sandstrom one thing that I know has been tossed around before is moving the majority of the computed properties into an addon and then having that addon be included in ember-cli in the default blueprint. I think an RFC around that could potentially get more traction and by in.

[webark]

this would give the "novice" user more default "tools", but allow the core to be smaller and allow people who are more familiar with the eco system the control they might desire.

[locks]

@sandstrom @NLincoln I just want to point out that the PR was not accepted due to the lack of the respective RFC.

[edit] I see that OP closed the PR on their own, dunno if out-of-band conversation was had, but the above still stands.

[sandstrom]

@webark Good point! Though one downside with including things in ember-cli that adds API-surface, is that it won't be covered in the guides or documentation. It may be that useful to newcomers.

What would be some computed property macros that people think should be included? What is a reasonable upper limit or cap, where should one draw the line (if the set is to be included in ember-cli by default)?

Suggested CPMs:

• sortBy
• includes

Here is some inspiration:
https://www.npmjs.com/package/ember-awesome-macros
https://www.npmjs.com/package/ember-cpm
https://www.npmjs.com/package/ember-computed-sortby

[locks]

Though one downside with including things in ember-cli that adds API-surface, is that it won't be covered in the guides or documentation.

Are you saying that Ember Data isn't covered in the guides or documentation? ;)

[sandstrom]

@locks Good point 😄 Maybe it could be added to the docs, I don't know enough about the documentation part of Ember to answer

[locks]

Is this still relevant in the current tracked properties world?