Comments (15)
@adriaanvanrossum set’s are still needed.. :/ and some gets.. but ya!! It’s getting better!! And you’ll have to do less typing too!! 😁😜😇
from rfcs.
As noted above, CP's can be used without Ember.get
as of Ember 3.1 (assuming you aren't using unknown property), and soon on canary (~ Ember 3.13) CP setters will be allowed without using Ember.set
.
Closing...
from rfcs.
Less typing
Not an argument.
Again, not proposing the removal/deprecation of get/set.
Why not?
from rfcs.
i like the idea of just: Ember.get(myObj, 'myVal')
/Ember.set(myObj, 'myVal', 'foo')
.. if you are concerned about native/computed properties.. ember/non-ember objects.
from rfcs.
Less typing
Not an argument.
Why not? Given two lines that function the same and are ~equally grokkable I'll happy take the shorter one.
But granted, not the most important argument.
Again, not proposing the removal/deprecation of get/set.
Why not?
Still has some value for a tiny, specific set cases, like if you want to make a Map-like object.
I like the idea of just:
Ember.get(myObj, 'myVal')
/Ember.set(myObj, 'myVal', 'foo')
.. if you are concerned about native/computed properties.. ember/non-ember objects.
But I don't think you should have to worry about it at all. It's still a trap.
And JS already has accessors - why not leverage them?
from rfcs.
For the get
case this is (in my opinion) a no-brainer, there is however value in explicitly calling set
as it makes changes to state more obvious. Also, wasn't this already discussed around the decision to drop ie8/9 compatibility?
from rfcs.
Hi, @jonnii,
there is however value in explicitly calling
set
as it makes changes to state more obvious
Can you expound on this?
I'm not sure how:
myObj.set('computedProperty', 1234);
Is more obvious than:
myObj.computedProperty = 1234;
Assignment is assignment, no? (I, myself, read these the same.)
from rfcs.
the get
case is planned to happen ever since we dropped ie8 (Everyone is on board, work just needs to be done), just requires a multi-release process, as descriptors as emberjs/ember.js#10323 accidentally opened leaked descriptors into the object...... This will need to be deprecated (to be nice to those that have begun relying on it)
quick example of the issue we will need to deprecate (and why i haven't already just done get -> ES5 descriptor)
init() {
this._super(...arguments);
this.foo = Ember.computed.alias('bar') // this due to #10323 makes `foo` a descriptor alias to bar...
}
The set
will need more exploration, but I believe as @jonnii mentioned the current thought is to leave the explicit set, to make it clear set
is for change tracking, not just assignment.
from rfcs.
@chrisjshull a better example would be setProperties
.
from rfcs.
Another reason to keep around get/set methods even with native accessors:
The getPath/setPath abilities of get/set are quite useful, in cases where you actually want undefined
out of "broken" paths. Saves a lot of typing vs checking for null/undefined in each part of the path.
@stefanpenner, for set
would native assignment also be supported in that current thought?
(If not, it would seem awkwardly non-parallel to support native get without native set.)
from rfcs.
Another reason to keep around get/set methods even with native accessors:
we have no plans on removing get
/set
(needlessly removing things that would break apps, seems poor choice, and proxies/paths must use the get approach anyways) but allowing for native ES5 descriptor variant of get
, for set would native assignment also be supported in that current thought?
I believe the current thought, is to only support explicit set
variant, to obviously say "this is being changed, and it should be tracked". This is something @wycats has mentioned, before I speak for him, he should likely be the one to response. (pinged him in chat)
from rfcs.
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 foo
. Internally whenever that property changes I need to make sure I do something. Why must the API consumer be aware of that fact? It's not the API consumer who needs to make the call of "should this be tracked", but the API's internals.
And you still have the upgradability issue, where foo
is a plain old property and everyone is safe to use native getters and setters. Until the day I need to add that observer or dependent computed property and have to break all of those consumer's setters.
from rfcs.
@wycats, sounds like your thoughts were desired...?
from rfcs.
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.
from rfcs.
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
No more #108 (comment)get
's and set
's!
from rfcs.
Related Issues (20)
- NVP todos
- Deprecate all of Ember Classic HOT 16
- Build-time configuration of index.html HOT 3
- Deprecate support for Travis CI HOT 6
- Deprecate `ember-mocha`? HOT 2
- Deprecate `ember-export-application-global` addon? HOT 4
- Run Prettier separately in `app` blueprint HOT 9
- Deprecate `app.import`
- Thoughts on this more ergonomic way to wire up the owner + destroyable association? HOT 2
- Explore "official" pod deprecation HOT 19
- {{else}} should render a value rather than be a control-flow keyword. HOT 5
- new primitive: transition, similar to modifiers, except they block certain render events HOT 2
- Numbers in PR titles affect automation
- Asset import spec RFC HOT 2
- Implement import spec RFC HOT 1
- Replacing `moduleName` in template meta HOT 11
- Simplified imports for common built-in modules HOT 2
- Pre-RFC: Add `aria-current` attribute to Ember's `LinkTo` component HOT 1
- Whitespace handling for `<template>` tag HOT 4
- Add LICENSE
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rfcs.