Site numbers furo-ui5-pagination-bar

[MarcOmlin]

I discovered an issue with the pagination current-page value. Maybe it is because i dont use hateos the right way.

For default display ill use a limit of 23 items.
The hateos link for the relation self of the collection has no page-parameter information. Lets say page is 0 or empty.
The furo-ui5-pagination-bar displays that the current-page is 1 what i think is right in the perspective of the user.
This behavior is because the getCurrentPage() uses 1 as defaultvalue if no page value is definied.

  /**
   * get current page number via self link: page=xx
   * @private
   * @param href
   */
  getCurrentPage(href) {
    // assume that we are on the first page, if the qp "page" is not set
    this.currentPage = 1;
    if (href) {
      const regex = /page=[\d]*/;
      const page = href.match(regex);
      if (page && page.length > 0) {
        this.currentPage = page[0].substring(5);
      }
    }
  }

When i now step to the next page of the pagination and trigger href next.
Then ill get the next 23 items. The link self of the collection now has a page-parameter but i set it to 1 page=1.
This will also show the current-page is 1. But it should change to current-page 2.

I preffere the attempt to start with current-page 1 not page 0. But how do i fix the next step?

Should i use a server generated page offset inside my hateos? Then i think the component would work fine.
Or i could change the component to show the page number page 1 if no page attribute is found in the link and otherwise display the value of the page-parameter +1 as the current-page of the pagination-bar.

Im not sure what the definition of theres hateos-attributes is. So this could be a bad or wrong idea.
But if not this solution would also work if its possible to submit a page-parameter with the value 0. This would then also be represented as the current page 1.

Thanks Marc

[veith]

I think an attribute like page-param for the used query param, which defaults to page and also a parameter first-page-index which defaults to 1 (like the current behaviour).

The UI should not force the API to have a index which begins at 1.