Closed shellyear closed 4 months ago
@blcham I've implemented it like this. When the pageNumber is equal to the pageCount, the pageCount disappears.
@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:
Source: https://fireart.studio/blog/pagination-design-examples/
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 | > | >>
)
@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 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 theseli
elements depends on ellipsis, which depends on thepageCount
and thepageNumber
@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 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 theseli
elements depends on ellipsis, which depends on thepageCount
and thepageNumber
@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
https://github.com/kbss-cvut/record-manager-ui/issues/153