


























– By Stanley Stuart
Long-time contributors Brendan McLoughlin and Sylvain Mina have been given collaborator status and will help us triage issues, merge pull requests, and contribute bugfixes and documentation.
When using Ember Data, the most common pattern in the model hook is to call
store.find for your model:
export default var PostRoute = Ember.Route.extend({
model: function(params) {
return this.store.find('post', params.post_id);
}
});
store.find will return the instance of the Post record if it has already
been fetched in the store. Sometimes, this is not desirable. For example, you
may not know if you have already loaded the post in another request via
sideloading, or you want the most up to date information. You could either
check if the record existed using
store.hasRecordForId, or always call
reload on your model in the route's afterModelhook.
store.fetch wraps this common pattern by reloading a record if it exists in
the store, or reloads the record if it doesn't exist:
model: function(params){
return this.store.fetch('post', params.post_id);
}
Please give a warm thanks to Tom Coquereau for his pull request implementing this feature!
Prior to Ember Data v1.0.0-beta.11, the following code would give you direct access to a record:
var post = store.createRecord('post');
var comment = post.get('comments').createRecord('comment');
In beta.11, it returned a Promise, meaning you couldn't call things like
set/get on the resulting record. This regression has been fixed in beta.12
thanks to Sébastien Grosjean.
A bug in Ember 1.7's Ember.create method (which is a polyfill for
Object.create) combined with a bug in es5-shim's Object.create prevent us
from giving Ember Data users a good alternative to use. Internally, Ember Data
uses Object.create for efficient caches. Ember 1.8 ships a working
Object.create polyfill on Ember.create so if you are using Internet
Explorer 8 and Ember Data in production, you should upgrade to Ember 1.8 as
soon as you can.
If you are using browsers that provide Object.create, you do not need to do
any additional work here. This includes mobile browsers, evergreen browsers
(Chrome, Opera, Firefox), Safari, and IE9+.
Ember Data relies heavily on JavaScript language-level shims (such as the
Object.create issue mentioned above) and other useful internals that Ember
provides. Rather than creating our own detection algorithms and more polyfills
for broken code in Ember 1.7, we are deciding to drop 1.7 support in the next
release of Ember Data. We do so in order to not increase the final size of
Ember Data's build. You should upgrade to Ember 1.8 as soon as you can.
data For Changes Has Been RemovedAlthough model.get('data') has been private in Ember Data for a long time, we
have noticed users may subscribe to changes on data for any change to the
model's attributes. This means that the following code:
var Post = DS.Model.extend({
doSomethingWhenDataChanges: function(){
// do the work
}.property('data')
});
no longer works. Instead, you should watch each attribute like you
would with any Ember.Object:
var Post = DS.Model.extend({
name: DS.attr(),
date: DS.attr(),
doSomethingWhenDataChanges: function(){
// do the work
}.property('name', 'date')
});
This change fixed some bugs around observers. Thanks to Christoffer Persson for helping to clean this up and fix some observer bugs around this!
Thanks to Christoffer Persson for helping us implement bugfixes and API changes, as well as triaging issues.
[road-to-1]: http://emberjs.com/blog/2014/03/18/the-road-to-ember-data-1-0.html
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。