-
-
Notifications
You must be signed in to change notification settings - Fork 407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gathering feedback: Support native ES properties for computed properties #108
Comments
Not an argument.
Why not? |
i like the idea of just: |
Why not? Given two lines that function the same and are ~equally grokkable I'll happy take the shorter one.
Still has some value for a tiny, specific set cases, like if you want to make a Map-like object.
But I don't think you should have to worry about it at all. It's still a trap. |
For the |
Hi, @jonnii,
Can you expound on this? myObj.set('computedProperty', 1234); Is more obvious than: myObj.computedProperty = 1234; Assignment is assignment, no? (I, myself, read these the same.) |
the quick example of the issue we will need to deprecate (and why i haven't already just done get -> ES5 descriptor)
The |
@chrisjshull a better example would be |
Another reason to keep around get/set methods even with native accessors: @stefanpenner, for |
we have no plans on removing
I believe the current thought, is to only support explicit |
If indeed the thought is that native get would be supported, but not native set, I can only see that being super confusing due to lack of parallelism, leading to more hard-to-diagnose issues. Moreover, it's forcing what is potentially an internal concern onto API consumers. Let's say I create an API with a property And you still have the upgradability issue, where |
@wycats, sounds like your thoughts were desired...? |
I have some work that does this, but performance is a concern. Once that is completed (35 remaining failing tests), more thorough performance work will be completed at which point we can re-evaluate. |
In ember-cli/ember-cli-update#255 I figured Ember.js is now supporting getters with traditional object dot notation for computed properties. So for other people coming here, this is now supported: import Component from '@ember/component';
import { computed } from '@ember/object';
export default Component.extend({
name: computed('firstName', 'lastName', function() {
return `${this.firstName} ${this.lastName}`;
}),
message: computed('name', function() {
return `Hello ${this.name}!`;
})
}); emberjs.com/blog/2018/04/13/ember-3-1-released.html
|
@adriaanvanrossum set’s are still needed.. :/ and some gets.. but ya!! It’s getting better!! And you’ll have to do less typing too!! 😁😜😇 |
As noted above, CP's can be used without Closing... |
This issue is intended to gather feedback on making computed properties gettable and settable via native properties (in addition to the
get
/set
methods).For example, instead of:
You could do:
Benefits:
get
/set
.get
/set
all the time "just in case". ** Even if you do this, it can't be applied across the board since you still have to deal with native/non-Ember objects which don't have
get
/set
.Drawbacks:
unknownProperty
obviously won't work if you don't actually callget
/set
.unknownProperty
is rarely used - classes tend to declare all of their actual properties. However, if your object actually takes arbitrary properties (like an ES Map),get
andset
will still be there for you.Again, not proposing the removal/deprecation of
get
/set
. If you like the methods better, or have use ofunknownProperty
then they will still be there for you. But I think it would be nice to use native accessors for the majority of cases where you don't even wantunknownProperty
.The text was updated successfully, but these errors were encountered: