Relevance of @ember/object/computed macros when there is ember-awesome-macros

[YoranBrondsema]

Over the past few months, I've found myself using almost exclusively macros to define properties. I'm hardly writing any properties simply with computed. The syntax is more declarative and there are no issues with keeping the list of dependencies in sync with the implementation.

In doing so, I've been using mostly the ember-awesome-macros addon instead of the macros defined in @ember/object/computed. Three reasons:

1. The macros in ember-awesome-macros are composable which avoids having to name intermediate properties.
2. Minus a few exceptions (e.g. intersection), all macros in @ember/object/computed are also available in ember-awesome-macros.
3. The ember-macro-helpers helps defines custom macros easily.

For those three reasons, I think that ember-awesome-macros is the superior technical solution for macros for Ember.js users.

However, there can be some confusion now due to the overlap in functionality between the two. For instance, the not macro exists in both packages:

import { not } from '@ember/object/computed';
import { not } from 'ember-awesome-macros';

One is composable, one is not.

Given the confusion, would it make sense to replace the existing @ember/object/computed package with ember-awesome-macros, and thereby "promoting" the latter to an official Ember.js package? Of course, the macros missing in ember-awesome-macros would have to be ported.

[rwjblue]

Thanks for writing this up! I think this is more of an RFC in the works than a bug (which is what we generally like to track here in the issue tracker). Would you mind opening this as an issue in emberjs/rfcs repo instead?

[YoranBrondsema]

Thanks for your prompt reply @rwjblue. I posted it as an RFC issue here: emberjs/rfcs#349.