The previous way of handling pagination (up to v0.13) was to return a meta object as part of the response, but this functionality was removed (the whole extractMeta functionality in the default DS.JSONSerializer)
Are any thoughts/ideas on how pagination will be handled in Ember Data 1.0 ? Is the meta object handling coming back?
I am interested to know the answer to this as well. Any help would be appreciated.
I do have an alternate solution for this (if you are in control of adding your own server API) and curious to see if anyone’s implemented something like this to get pagination working. In this example I’m trying to get pages for an “assessment search”.
You could hit an API like so: http://baseurl/AssessmentPage?page=2&filter=XYZ, which can internally reroute in the server to GET /assessments?page=2&filter=XYZ and package up the results nicely.
Having said that, a “proper” way of doing pagination would be nice.
I’m upgrading to EmberDataBeta2 from EmberData 0.13.
In 0.13 I extend the adapter to include meta object but I think that you are using another way to do it.
Can you explain me how extractMeta works?
I got meta data like this.
App.AnyModel = DS.Model.extend({
anyAttr = DS.attr('string');
});
App.AnyController = Em.ArrayController.extend({
actions: {
anyAction: function( ){
@store.find('any_model').then(function(records){
// Is there any other way to extract meta data?
// I know this is ugly XD!
// Any sugestions?
records.store.typeMapFor(records.type).metadata
});
}
}
});
@wycats has asked we open a discussion on the future of the meta property in Ember Data 1.0 final.
As stated in the PR, there is no guarantee that this will make it into 1.0. We need to work out if this is the right solution moving forward.
I’m thinking that having the meta property available keeps it very flexible. Perhaps this leaves it open for misuse.
Personally, I’m using it for both pagination/counts, and also search engine facets. Both of these require binding at the template level.
The previous solution (typeMap.metadata) was not adequate, because it stored a single meta hash globally at the type level. This caused problems when we requested 2 queries of the same type.
I don’t want to dictate what the API should be, but for sure using store.typeMapFor(Post).metadata to get the metadata I just sent back is not good. That information should be accessible from the record array, and not bound to the model. What if I had two Post queries going off at once, which one’s metadata are we looking at? Metadata returned from the query should somehow be exposed to the record array.
I’d appreciate an explanation for how pagination is currently supposed to work in Ember Data (1 beta 7)?
In particular, if I make a query to get all posts for a user:
var posts = this.store.find("post", { userId: userId });
And my API returns pagination information in a “meta” field in the response, how do I retrieve that meta data?
(I’ve tested calling this.store.metadataFor("post") and it does return the data for this query. I’m assuming that that returns the metadata for whatever the last query of post is. So it works in this case, but surely only accidentally because there is currently only have 1 post collection on the page. Perhaps it also means that if the user navigates from a global post list to a sublist of posts the global pagination information will be clobbered, so if they return to the global list the pagination will be wrong then? In any case it doesn’t seem like the solution.)
Thankyou Alex! As you told me in our conversation yesterday, its also worth noting that to retrieve the meta from the posts object that is a result of the query, you can do this:
Hey @alexspeller and others, to continue on with this thread…
I’m interested in using meta properties for paging a nested resource (each User has many Notes). Any ideas/solutions for storing page meta info for these?
I’m thinking I can just put the meta information within the user, then whenever I receive a request from the server, I update the Note pagination information for the specific Use (so set metas for the user, not the notes). It feels roundabout, but it seems like the only way to go.