Platform: Implement pagination into ngrx/entity

Created on 4 Jan 2018  路  5Comments  路  Source: ngrx/platform

I'm working on application that does a bit of server-side paging for long lists of things. There's a lot of repeated code in different reducers to handle pagination (lists of IDs on every page, current page, etc) and I'm starting to think of ways to make my implementation more DRY. I already use ngrx/entity and this seems like great functionality to be rolled into that portion of the library (since it is aimed at reducing boilerplate in the "entities" section of a reducer).

I'm just creating this issue to throw the idea out here and see what people think. I'd be willing to propose a design (and maybe even create a PR) at a later date.

I know lots of SPAs and APIs handle pagination differently (offset/limit vs pageNumber vs hasMore and paging vs infinite scrolling), so I'm actually not sure how realistic this is now that I think about it...

Entity enhancement

Most helpful comment

Pagination is very subjective to which solution you want to use, and entity is for managing the collections so you can build your own pagination adapter on top of it.

All 5 comments

Pagination is a PITA. Maybe examples in gist form using existing entity API. Then expanding from those into ngrx entity per pagination implementation type?

HATEOAS is probably the closest thing to a common standard I can think about when it comes to pagination. But I'm not sure how widely it is used among APIs.

In the Yii Framework as example you get a similar headers response to this when requesting a collection:

HTTP/1.1 200 OK
...
X-Pagination-Total-Count: 1000
X-Pagination-Page-Count: 50
X-Pagination-Current-Page: 1
X-Pagination-Per-Page: 20
Link: <http://localhost/users?page=1>; rel=self, 
      <http://localhost/users?page=2>; rel=next, 
      <http://localhost/users?page=50>; rel=last

In such case, It doesn't really matter how URL structure is, or if it expands other resources, or if it includes sorting, limits, filtering, ... as server should take care of returning back full path to next, previous, first and last pages plus proper meta data as in the response above. You may only need to know the parameter to request a specific page by number. In case of Yii, this is a simple (but old) angularJs 1.x service as example consuming it. But again, I don't know how widely HATEOAS is used among APIs. In case it is pretty well used then won't be easier to give support to such standard rather that supporting pagination with all possible designs out there?

Another spec that is used quite a lot in the Rails world is JSON-API spec. It details pagination here and appears at first glance to be similar to HATEOS.

Pagination is very subjective to which solution you want to use, and entity is for managing the collections so you can build your own pagination adapter on top of it.

Hello guys, I have the same question asked by @jongunter and I did it in my project in a way that worked for me:

https://github.com/peimelo/controlled-health-frontend/tree/master/src/app/weights

Was this page helpful?
0 / 5 - 0 ratings