define and use custom parseLinkHeader function in pagination

[shellyear]

#153

[shellyear]

@blcham I've implemented it like this. When the pageNumber is equal to the pageCount, the pageCount disappears.

[blcham]

@shellyear, To me, it looks a little strange (@LaChope, what do you think, is it ?). Please do a little research on how to show it, or I suggest the following:

I.e. to summarize I suggest:

• adding a separator between the first and last page "..."
• move last page before button ">"
• [OPTIONAL] add more buttons representing concrete pages

Source: https://fireart.studio/blog/pagination-design-examples/

[LaChope]

Yes, I think there should be up to 5 numbers (if they exist), if they are more than 5 then separate with "..." until the last page. And all the pages should be in between the arrows (e.g. << | < | 1 2 3 4 5 ... 12 | > | >>)

[shellyear]

@blcham The test in https://github.com/kbss-cvut/record-manager-ui/blob/main/tests/__tests__/components/Pagination.spec.jsx is written for a pagination with "first, previous and next button" and as for the single current "active" page too. So it expects it to be deeply equal 4, which fits the idea of the previous pagination implementation.

My suggestion is to rewrite the test, and use pageCount as well, so an expectation will be "expect(li.length).toEqual(number of pages + those three buttons)" ; ItemCount is not necessary anymore, the new implementation does not rely on it

UPD:
the pagination items include not only the pageNumbers, but also ellipsis (which is a li element), and the number of these li elements depends on ellipsis, which depends on the pageCount and the pageNumber

[blcham]

@blcham The test in https://github.com/kbss-cvut/record-manager-ui/blob/main/tests/__tests__/components/Pagination.spec.jsx is written for a pagination with "first, previous and next button" and as for the single current "active" page too. So it expects it to be deeply equal 4, which fits the idea of the previous pagination implementation.

My suggestion is to rewrite the test, and use pageCount as well, so an expectation will be "expect(li.length).toEqual(number of pages + those three buttons)" ; ItemCount is not necessary anymore, the new implementation does not rely on it

UPD: the pagination items include not only the pageNumbers, but also ellipsis (which is a li element), and the number of these li elements depends on ellipsis, which depends on the pageCount and the pageNumber

@shellyear Not sure that I understand, but if the implementation changed, fix those tests so they test a similar part of the implementation and do not implement new tests.

[shellyear]

@blcham The test in https://github.com/kbss-cvut/record-manager-ui/blob/main/tests/__tests__/components/Pagination.spec.jsx is written for a pagination with "first, previous and next button" and as for the single current "active" page too. So it expects it to be deeply equal 4, which fits the idea of the previous pagination implementation.
My suggestion is to rewrite the test, and use pageCount as well, so an expectation will be "expect(li.length).toEqual(number of pages + those three buttons)" ; ItemCount is not necessary anymore, the new implementation does not rely on it
UPD: the pagination items include not only the pageNumbers, but also ellipsis (which is a li element), and the number of these li elements depends on ellipsis, which depends on the pageCount and the pageNumber

@shellyear Not sure that I understand, but if the implementation changed, fix those tests so they test a similar part of the implementation and do not implement new tests.

@blcham I mean in the past, there were overall 4 li elements in the pagination: first page arrow button, prev, next, last page arrow buttons. But now the amount of the li elements depend on if there are more a lot of elements, number of the current page, if there are left or right ellipsis. That's why I suggested to change this tests a bit, because this particular does not fit the idea of having fix amout of li elements in the pagination, now the amount of li elements are dynamic

[blcham]

LGTM, rebasing and merging