In some cases pagination component hides only one page by ellipsis

[dmytroyarmak]

Bug description:

There is a case when pagination component inserts ellipsis instead of just one page. I think it will be more useful for a user to show this page instead of the ellipsis.

For example for:

• page numbers: 10
• current page: 7
• max pages: 3

The current result is:

['« Previous', '1', '-...', '6 , '+7', '8', '-...',  '10', '» Next']

But maybe it will be better to show 9th page in this case. It will be the same number of elements:

['« Previous', '1', '-...', '6 , '+7', '8', '9,  '10', '» Next']

The same problem happens on the 4th page.

Link to minimally-working plunker that reproduces the issue:

http://plnkr.co/edit/sbawSfKJcyIGBQFAC0JC?p=preview

Version of Angular, ng-bootstrap, and Bootstrap:

Angular: 2.0.0

ng-bootstrap: 1.0.0-alpha.18

Bootstrap: 4.0.0-alpha.6

[dmytroyarmak]

@pkozlowski-opensource if you think that it's a valid issue, I can fix it

[maxokorokov]

I'm conflicted about this change. Depends on what is more important: respecting the rotation == 3 or the fact that ellipsis should be shown only if there are > 1 pages hidden behind it.

A dedicated flag for this should solve this for me, but for now I'm against adding it to the API :)

So I would leave it as is.

Example with a little more context:

// rotation = 3
1 ... 8 [9] 10
1 ... 7 [8] 9 10
1 ... 6 [7] 8 ... 10  <--- versus  1 ... 6 [7] 8 9 10
1 ... 5 [6] 7 ... 10

5 pages' example: #1166 (comment)

[dmytroyarmak]

@maxokorokov Yeah, I understand that component is trying to respect "max size" parameter and shows only specified number of pages, but I'm not sure this behavior is better for an end user.

In my mind, the more options user sees, the better. And showing "..." instead of one page doesn't improve UX.

The same approach is implemented in angular-ui/bootstrap.

I think there is a better option than respecting a number of items around current - it's respecting the total number of elements (buttons with page numbers or ellipsis) inside pagination. It's more useful because it makes a width of pagination more predictable than when the width is changing when you are on different pages.

For example now for 10 pages and "maxSize"=3 case in ng-bootstrap we have:

Current Page	Number Of Elements
1st page	5 elements (4 pages + 1 ellipsis)
2nd page	5 elements (4 pages + 1 ellipsis)
3rd page	6 elements (5 pages + 1 ellipsis)
4th-7th page	7 elements (5 pages + 2 ellipsis)
8th page	6 elements (5 pages + 1 ellipsis)
9th page	5 elements (4 pages + 1 ellipsis)
10th page	5 elements (4 pages + 1 ellipsis)

As you can see, number of elements is changing from 5 to 7 and, as a result, the width of pagination is also changing.

Here is an example of paginator that respects total number of elements (for the same configuration as described before it always shows 7 elements): http://ultimate-pagination.github.io/react-ultimate-pagination-examples/

The logic behind it is implemented as a separate framework-independent module: https://github.com/ultimate-pagination/ultimate-pagination

And if you like this approach I would like to enhance ng-bootstrap/pagination either by improving ultimate-pagination core and using it inside ng-bootstrap or by reimplementing the same pagination logic directly in ng-bootstrap/pagination source code.

[pkozlowski-opensource]

@dmytroyarmak if you still up to improving the pagination component we would love to see a PR. I'm "buying" your reasoning that we should optimise for pagination's no of elements vs. no of shown pages.

I would love to keep external dependencies to the minimum so we are not ready to bring in ultimate-pagination but if you could replicate the same behaviour in-here it would be awesome!