JSONAPIAdapter: Pagination when using store.findAll

Ember Data
1

How can I pass pagination information to the server when using store.findAll? When using store.query I could (mis?)use the query object. But how to pass such parameters when using findAll?

2 
model: function (params) {
    var query = {};
    
    if (Ember.isPresent(params.page)) {
      query.page = params.page;
    } else {
    query.page = 1;
    }

    if(Ember.isPresent(params.page_size)) {
        query.page_size = params.page_size;
    } else {
        query.page_size = 10;
    }

    return this.store.query('shipment', query).
    catch(err => this.send('error', 'Boom!'));
},
3

Sorry but my question was how to do paging using findAll. I’m aware that I can pass arbitrary parameters using query. If I understand it correctly findAll and query have different behaviors.

4

If your server’s API is paginated, query is the only way to pass the needed page parameter as findAll does not allow you to pass such a param. At least I think so…

5

Alright, thanks! I see less and less reasons every day why I should use Ember Data.

6

Because it is really smart and frees you from re-inventing the wheel? :grinning:

7

That might be the case for some. But I have the feeling as soon as there is something it can’t do right out of the box you have to invest many hours into understanding the inner workings of this quite complex framework in order to make a change at the right place.

Since I’m still new to Ember Data could you tell me what it can offer me that I would miss if I went another route? I’m aware of caching and reference resolution.

8

For my experience, the Ember patterns are really useful to cover about 95 percents of my needs. I’d always consider to change my app’s structure to fit better into the Ember world. If you want to use such an opinionated framework, you should not fight against it and play by the rules.

I agree, it is fairly complex but once you’ve mastered it, it enables you to re-use a lot of your code. I still enjoy the model-driven approach as it teaches you to think twice about the things you want to build.

By the way: Every time I struggle with Ember’s complexity and always if I am in doubt if something special can be achieved with Ember I take discuss.emberjs.com as example what wonderful stuff can be build with it. :slight_smile:

Martin

9

I also try my best to do things the Ember way. But especially when it comes to interaction with external services this can be hard. Anyway, thanks for your insight! :slight_smile:

10

Pagination and findAll() doesn’t really play nice together since findAll() will give you a “live array” with all the current/future records in the store of the specified type. query() does a much better job of giving you a sub-set of data.

That said, you can pass { adapterOptions : { ... } } as the second argument to findAll() and then access the adapterOptions in your adapter.

1 Like
11

How does the “live array” work and how can I achieve this functionality with query?

12

findAll will return a DS.AdapterPopulatedRecordArray that will update as you create and destroy records. query on the other hand returns a DS.RecordArray I believe. With a query, you will need to handle refetching the results when there is a change.

I haven’t messed with pagination a whole lot with Ember so I am not sure what the best way to do that with ED is.

1 Like
13

Assuming it hasn’t changed recently, Discourse and thereby discuss.ember.com don’t use Ember Data. Were you aware of this?

I do not think anyone is begrudging the complexity of Ember, rather the complexity of Ember Data. Although ED is now seeing the favor of the core team, I think some are forgetting that you don’t need one to use the other. I’ve seen the (ab)use of ED leave people frustrated with Ember, even though they are not one in the same.