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

[YoranBrondsema]

ember-awesome-macros vs @ember/object/computed

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 mostly been using the ember-awesome-macros addon instead of the macros defined in @ember/object/computed. There are three reasons I prefer the ember-awesome-macros addon:

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 allows you to easily define custom macros.

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

However, in the current state of affairs, there can be some confusion 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.

Proposal

Given the confusion, I wonder if it would 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. This under the assumption that ember-awesome-macros is technically superior to @ember/object/computed.

Concerns

Missing macros

Some macros, e.g. intersection, are available in @ember/object/computed but not in ember-awesome-macros. Since they are part of the public API, they would have to be implemented in ember-awesome-macros too.

Code size

As a first concern, I think that ember-awesome-macros is heavier in terms of code size as it contains more macros. However, with tree-shaking coming around the corner, I don't think that should be a big concern.

Different behavior

Secondly, ember-awesome-macros is not a drop-in replacement as it treats arguments as names of properties instead of values. An example will make it clearer:

import { equal } from '@ember/object/computed';

color: 'red',
isRed: equal('color', 'red') // true

In ember-awesome-macros, the second argument is not a value but a property name instead.

import { equal } from 'ember-awesome-macros';

color: 'red',
isRed: equal('color', 'red') // false as it tests whether the property `this.color` is equal to the property `this.red`

to get the same behavior as for `@ember/object/computed':

import { equal } from 'ember-awesome-macros';
import raw from 'ember-macro-helpers/raw';

color: 'red',
isRed: equal('color', raw('red')) // true

Maybe a codemod can help in automatically making this transformation.

[tomdale]

@YoranBrondsema Thanks for the write-up!

I agree the ember-awesome-macros API is quite nice. I think that if we were continuing to invest in computed properties as they are today, your proposal to adopt the ember-awesome-macros API would be a good idea worth exploring.

That said, our plan going forward is to move to tracked properties, which don't require users to enumerate dependencies, and thus reduce the need for things like CP macros.

Given that, I don't think it makes sense to introduce changes to the CP or macro APIs, and ask users to spend time to adopt them, when we ultimately expect people to move to tracked properties instead.

[YoranBrondsema]

Thanks for your reply @tomdale. I didn't know about the evolution to tracked properties and looking at the RFC, it does indeed solve the problems of CPs that macros solve. Pretty excited for that move!

I'll close the RFC then.