Pagination of top communities in the Dashboard

[abollini]

Not all the DSpace top communities are shown in the dashboard as our service make the REST call with default parameters (100 communities)

[abollini]

progress on that will be shared here: https://github.com/abollini/angular2-ui-prototype/tree/pagination-top-communities

[wellingWilliam]

With required server side rendering of REST paged responses this is not an easy task. I am investigating solutions for item pagination and am realizing we will need pagination for communities and collections as well. A potentially easy solution may be to maintain a synched copy of the DSpace directory on the node server. I think this is to much duplication of data. However, may align with future designs of serving the Angular2 app from Spring boot.

Lazy-loading client side paging may be somewhat difficult with the given hierarchical directory. Without the entire community/collection or items list readily available paging will require making lazy requests for any given page and some type of caching of previous retrieved pages. This caching would only be able to be leverage on the client side using JavaScript. The server side would have to make each request for a page lazily. Unless of course the server side node synchs the directory.

I have some ideas and am attempting implementation. The current problem I am experiencing is the navigation between pages. It could easily be achieved through click events, but wont satisfy noJS navigation. Therefor, the static html must be composed of anchor tags which resolve with the given context and the desired page of the list. I was thinking we had a good approach to the hierarchical navigation with the tree component and fairly reasonable session caching of the responses. Now I am thinking this adds a rather complicated problem with pagination. What I hope to be able to implement is asynchronous routing and router links to resolve static html anchors.

Here is a package I am also looking into to see if it sheds some light:

http://www.developerhandbook.com/web-api/angular-2-server-side-paging-using-ng2-pagination/

[wellingWilliam]

ng2-pagination is not yet isomorphic. The pagination-controls do not render server side.

michaelbromley/ngx-pagination#19

[wellingWilliam]

Pagination of communities and collections could use additional properties on the community object returned from DSpace REST API. Number of subcommunities and number of collections.

I was successful with server side pagination of items.

#47

[abollini]

I'm looking to your solution for the item pagination and I will share my comments very soon. I'm still trying to figure out how we can accomplish this task without changing the REST api as I think this is a good exercise to understand how the language/framework is productive in not-ideal situation. For instance we will face with similar pagination issues when we will treat the facet. For these, it will be not possible, without major performance penalties or caching complexity on the server side, know exactly the pages number.

[tdonohue]

Just catching up here with discussions (sorry, was out sick earlier this week). Regarding @abollini's note, I think it's actually OK to not know the exact number of pages once we deal with facets (in the future).

Pagination could be considered as having two main goals:

1. Obviously, we want a nice client-side experience for users of the application. This could be achieved without knowing the exact number of pages they may be dealing with (even Google does this for large search results sets, they still let you flip between pages, but never show how many pages are in total, or even exactly how many items matched).
2. Then, we need a server-side experience that is similar, but allows crawlers to more easily grab everything of use for SEO.

For browse-by Communities/Collection/Items pagination, both of those goals are high priority (so that we achieve good SEO). So, I think it's great that @wellingWilliam was able to achieve this. I also think it is worth adding a ticket to have the REST API properly return these "known" numbers of subcommunities/collections, to help client-side apps (created a new DSpace-level ticket for this REST API enhancement: DS-3126)

But, for browse by facet pagination, we don't need to care as much about SEO / server-side experience, because crawlers shouldn't need to browse by facet. So, it seems reasonable to not necessarily give a total number of pages (if it's not easily determinable from the server side). In fact, in the current DSpace codebase, we specifically tell crawlers not to browse-by-facet (or filters) in our robots.txt

So, when dealing with pagination in general, I think we should be considering whether it's pagination that is also important to crawlers (so that they can index all content), or if it's pagination that we only need/want end users to perform.