macro blueprint

[kellyselden]

Rendered

[nathanhammond]

The existing patterns around this are all set by ember-cpm

I'm not sure if we get a ton of benefit moving this into Ember directly? Is it enough to point people to ember-cpm?

/cc @cibernox

[cibernox]

I personally think that an entry in the docs is enough. Besides, the blueprint would just generate

export default function(/*...keys*/) {
  return Ember.computed(/*...keys*/, function() {

  });
}

I think that the util blueprint mostly does this already, and the user has to understand how to computed properties work to create one anyway.

[kellyselden]

I think that the util blueprint mostly does this already, and the user has to understand how to computed properties work to create one anyway.

The util blueprint doesn't help in this case, because it gives you no guidance in how to structure the macro. This blueprint is meant to bridge the gap in helping a beginner understand how to set up a custom computed macro. I remember when I was starting out, I assumed the macros were another one of the deep magical things that ember does for you, and good luck if you want to customize.

I think having a blueprint as a starting point and a macros/ folder "convention" would really help out newbies.

[acorncom]

I think having a blueprint as a starting point and a macros/ folder "convention" would really help out newbies

I would concur. I've been around / using Ember for 2+ yrs now and am just learning that this is even an option 😀

[kellyselden]

Some things that came out of the cli core team meeting:

• This is a good thing, but needs ember core team approval.
• Including an accompanying test blueprint would help solidify the usefulness
• Should it live in app/utils/macros instead of app/macros?

[kellyselden]

I've added a testing blueprint to the RFC.

[locks]

I believe it should live at app/macros like other official collections, as well as some of the community provided solutions. If there happens to be a name collision it should be possible to address on a case by case. On the why not to use app/utils/macros, app/utils is the junk drawer of Ember applications. Suddenly doing nested collections, and doing it in app/utils seems confusing.

[tomdale]

While computed property macros are very powerful and useful, I'm not sure we can afford to add more conceptual weight to the Ember getting started experience. My preference is to keep the core constrained to the bare minimum amount of concepts, and leave education about macros (and thus this generator) to popular community addons like ember-cpm.

[nathanhammond]

@tomdale Does that comment represent the general consensus of the core team per today's meeting?

[cibernox]

I also subscribe that idea of narrow core, but I think that CP macros are useful enough to deserve an entry in the guides about how to create your own, maybe just after this point: https://guides.emberjs.com/v2.8.0/object-model/computed-properties/#toc_computed-property-macros

[tomdale]

@nathanhammond I believe so.

[nathanhammond]

@locks et al.: This then falls into the area documentation of advanced patterns in the Ember community and addons that we have which gracefully enable them. Just drawing this to your attention as another reference point.

Closing in favor of addon, not default-included in the app or addon blueprint.