Multiple pagination for DS.Adapter?

Ember Data
1

We’re in a situation where we’re using the server’s meta key to provide since and until cursors to our endpoint for the purpose of pagination.

Since these are adapter-level concerns, we’re having trouble allowing for two streams of models to use distinct pagination.

Has anyone had any experience in this domain?

For a more concrete example, imagine a messaging app with multiple streams of messages, all coming from the same endpoint. How would it be possible to keep separate the pagination information and allow each stream to be paginated separately?

2

@artsyca this is how we handle unorthodox meta information (pagination information from Django REST Framework)

https://github.com/dustinfarris/ember-django-adapter/blob/master/addon/serializers/drf.js#L34-L58

It sounds like you are already using the meta key, but I think you could override the same serializer method (extractMeta) to suit your needs.

3

@dustinfarris Thanks for the code example. This is exactly the approach we’re taking for meta.

However, the issue we’re experiencing is that it’s exactly that: metaForType (as opposed to metaForInstance say.)

How could we possibly have two separate paginations for the same type, on the same page?

For example: two message streams, one sorted by popularity and another by most recent. We’d get a new set of pointers with each call, which we’d want to store separately for use in future calls.

4

I think the only feasible solution is to paginate at application level, in one of the controllers associated to your page…

5

Thank you, and sorry for the lateness of this reply. This echoes my own thoughts. I’ll update this thread with any useful information once I have a solution.

6

So, in the end, the deal with model-level pagination amounted to writing some custom adapter code that stores the cursors on the model and then uses the same cursors to retrieve data next time the model is passed in!

It’s the best compromise that I can think of between the Ember idiomatic way of keeping cursors per-type and the need for our app to include multiple “pagination” sections on a single page.

The next beast we need to tackle: infinite scrolling… with cursors.