-
-
Notifications
You must be signed in to change notification settings - Fork 870
Encourage decorator-style Ember.computed/Ember.observer #110
Conversation
Really? Every ember project I've browsed seems to use them for convenience? When did the tide change? |
@stefanpenner Should prototype extensions be shunned because they introduce a performance penalty (or in plain English: because they are slow)? I guess the same then goes for |
this is part of a larger effort for ember to be a better ecosystem citizen. Basically, its extremely dubious to pollute globals as we currently do. Also, ES7 will give us annotations, which partially unlocks our path to using the new Class syntax provided by ES6. Transitioning from the
nah, no performance difference for these prototype extensions. |
Will we need to use Ember.A() all over the place? The extensions over array are actually the only extensions I find really useful |
This is a very big change and I think we need to be a little bit more deliberate in the messaging, if we want to make this recommendation at all. I personally find code written with prototype extensions easier to write and parse. Also remember that disabling prototype extensions has a significant performance cost due to the need to Personally, I would prefer that we frame this less as "let's stop using prototype extensions" and more "let's start aligning our syntax with ES7". Ideally, we could migrate folks over to the annotations API directly with Babel, and only have one mass migration instead of two. |
for now, some future RFC process will likely dig into that in more detail. So lets not dig into that here. The above changes, |
yes, a more detailed RFC can tackle this one. |
@stefanpenner Suggesting that everyone
I think this incremental step will cause more chaos than whatever benefits it provides, which are IMO pretty marginal. |
I argue that this isn't a big change, this is merely encouraging a different syntax that we already support. |
This PR has nothing to do with this, nore does it recommend this. We are merely encouraging using |
Ah, I see. Like I said above, I would rather just wait until we have annotations in Babel (which seems very close) and have people migrate en masse at once, rather than have an annoying transition period where new developers will find examples with |
this already exists, ^^ helps move people towards just We can add a blurb in the computed property guide, discussing what |
In fact I already favour Ember.computed/Ember.observer over the prototype extensions, but the observable interface un EmberArray is massively convenient. As Tom said, it might scare newcomers |
this effort does not touch this, some future investigation can dig into those. |
@tomdale - I completely disagree. It is much easier to read when you know the context (normal function, computed property, or observer) of a function before you get to the end. With |
For the computed properties change would it not be best to start off with re-writing the computed properties section first? Potentially providing a clear explanation as to why its a "best-practice" going forward? and a nod towards the current way people are writing it? (e.g removing the secion on alternate invocation and providing a replacement for the prototyped way of doing it) |
we can do that as part of this PR, and i am very much on-board with fleshing that part out. (Hence submitting the PR for review) |
@stefanpenner Sure, I guess in my eyes it might be a better straw man to knock down than just the syntax update. 👍. |
All this input is great, tweet + pr is succeeding in getting eyes and feedback! |
@stefanpenner The more I cruise through the docs, the more I realise theres a general inconsistency with how prototype extensions are mentioned / referenced. Perhaps a PR before this one could be a tightening up on that front. computed properties' "alternative invocation" vs observer's "without prototype extensions". Both of which ideally would link to their respective sections within the disabling prototype extensions page. |
I'm curious why this that can't be single consolidated effort? That would help ensure the tone/intent is unified on this topic. |
@stefanpenner Its close as it stands right now so I think its a matter of simply moving the two sections in the computed properties and observer pages into one place. Instead of trying to explain them differently in different places? |
that sounds good, I will try to word smith after my next two meetings. If you have any ideas feel free to submit a PR to my branch, or leave words here in comment. |
@stefanpenner Both pages could then signpost towards a single place for a potential "upcoming" syntax change? Or not ;). |
both syntaxes are currently available, this merely demonstrates that one that enables ember to be a better citizen in the JS ecosystem. |
👍, the proposed form reads much better. Also, If we do |
At DY we've worked without the It seems that most everyone here is in favor of suggesting the |
@abuiles it should likely not use a top level command name like that, maybe something namespaced |
Don't forget about the .on notation as well. Ember.on usage is also required. This plugin still doesn't cover this use case. Also, there are some places in the docs for observers where .observes('name').on('init') is specified, when we want the observer to be called on the initialization. How should we handle these cases? Ember.on('init', Ember.observer('name'... )) or Ember.observer('name, Ember.on('init', ...)) ? |
we can/could make
|
404c3c3
to
45f5865
Compare
Is there an idea of the timeframe for this? I think it makes sense to update the docs and change defaults so they're off by default would make sense, but completely removing them seems like unnecessary overhead for a lot of existing apps for 2.0. We could probably move that to an Add-on. |
clock.set('_seconds', seconds + (1/4)); | ||
} | ||
}, 250); | ||
}), 'init') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
http://emberjs.com/api/classes/Ember.html#method_on
on (eventNames, func)
isn't this backward? Shouldn't it be
Ember.on('init, Ember.observer('_seconds', function(){...}));
@stefanpenner what is the syntax for Is it just tacked on at the end still? This
becomes this
|
yes |
ping would really love to have this merged. |
I retract whatever rejections I may have had and am 👍 on migrating towards non-prototype-using examples, with the exception as discussed above about arrays. If |
@tomdale aren't most of the array prototype extensions pulled out anyway now? |
@bcardarella like |
@mixonic I'm referring to emberjs/ember.js@62916e8 |
http://emberjs.jsbin.com/devesujowo/9/edit?html,js,output I also think the guide needs a section on Arrays, explaining that the vanilla |
@bcardarella ah, I believe that PR just removes support for ES3 polyfills (IE8). We will continue to extend native array types with pushObject etc for the foreseeable future AFAIK. |
So the proposed looks like:
¹ Though the discussion suggests that It seems odd that we're moving from a consistent interface to one that can take one of two forms. Of course, this mostly becomes a non-issue with ES7 decorators where |
One valuable note regarding the convention to move away from reliance on prototype extensions in the default documentation is to promote addon development. Addon development requires development to support no prototype extensions by default. In addition to the default documentation supporting the |
will shortly go away entirely.
yes |
This PR has led to some great discussion, as well as some other PRs that have moved the state of the docs forward. However, the PR itself is out of date and mostly changes files that don't exist any more. I've just opened up #455 to summarize what needs to be done so that somebody can pick up the remaining work. If a couple of you who have been involved in this discussion can make sure that the issue correctly describes what needs to be done, that would be great! Thanks a bunch! |
Also, change code to emphasize ember.computed over function prototype extensions (per ember evolving recommendations) http://blog.ksol.fr/ember-js-declaring-computed-property-and-observers/ emberjs/guides#110 [#LEI-157]
lets encourage best-practices.
TL;DR we want to move away from prototype extensions.
So for today, lets tackle two simple ones.
.property
->Ember.computed
.observes
->Ember.observer
Further discussions about all other PROTOTYPE_EXTENSIONS, are more complicated and as they may result in development effort. They will go through the formal RFC process.
Topics for later discussion:
Ember.A
observer(..., fn).on
[edit: wording changes, based on feedback]