Difference with "@ember/object/computed" functions

[YoranBrondsema]

It's unclear to me how this module compares to the @ember/object/computed set of functions. Like what's the difference between the reads function from macro-decorators and from @ember/object/computed? It seems like they're both used the same way, as a decorator:

import { reads } from '@ember/object/computed';
import { reads } from 'macro-decorators';

@reads('foo.bar') baz;

It would be good to document this in the README: what the differences are and why one should be used over the other. I don't mind writing a PR for that but I want to understand it myself first :-)

[jordpo]

@YoranBrondsema good question. From what I understand it has to do with the different reactivity models between Octane and Classical. Here is the related Ember RFC issue emberjs/rfcs#536

[YoranBrondsema]

Thanks for pointing to the RFC, that explains it. I understand that @pzuraq is maybe hesitant to mention Ember at all in the docs for macro-decorators since the library aims to be framework-agnostic. But I think it could be useful to add a short blurb on the README for Ember users, cause I imagine most users of this library are Ember users (for now). The blurb would say something like:

Ember.js users: how do these decorators compare to @ember/object/computed functions?

The functions in @ember/object/computed are based on computed properties. This system has been replaced by tracked properties in Ember Octane. Eventually, computed properties will disappear all completely from the Ember.js framework. So we encourage you to use the macros from macro-decorators rather than from @ember/object/computed.