feat(web-core): create usePagination composable

[ByScripts]

Description

Introduces new usePagination composable allowing to separate the pagination logic from the component and allow full control over it.

All the logic has been removed from the UiTablePagination which now only declares props, model and events.

The composable takes an id which is used in URL and localStorage. This allows managing multiple pagination on the same page.

The "show by" setting is stored in local storage. It accepts the value -1, which means "all records".

The pagination system is based on the record index, not on "page". This allows sharing a link to a user using another "show by" value.

To simplify usage, the composable returns a paginationBindings object intended to be used with UiTablePagination:

<UiTablePagination v-bind="paginationBindings" />

The composable also returns a seek method, allowing to find a specific record and navigate to the page where it is.

The pageRecords property of this composable will contain only the subset of records for the current page.

Checklist

• Commit
  • Title follows commit conventions
  • Reference the relevant issue (Fixes #007, See xoa-support#42, See https://...)
  • If bug fix, add Introduced by
• Changelog
  • If visible by XOA users, add changelog entry
  • Update "Packages to release" in CHANGELOG.unreleased.md
• PR
  • If UI changes, add screenshots
  • If not finished or not tested, open as Draft

Review process

This 2-passes review process aims to:

• develop skills of junior reviewers
• limit the workload for senior reviewers
• limit the number of unnecessary changes by the author

1. The author creates a PR.
2. Review process:
   1. The author assigns the junior reviewer.
   2. The junior reviewer conducts their review:
      • Resolves their comments if they are addressed.
      • Adds comments if necessary or approves the PR.
   3. The junior reviewer assigns the senior reviewer.
   4. The senior reviewer conducts their review:
      • If there are no unresolved comments on the PR → merge.
      • Otherwise, we continue with 3.
3. The author responds to comments and/or makes corrections, and we go back to 2.

Notes:

1. The author can request a review at any time, even if the PR is still a Draft.
2. In theory, there should not be more than one reviewer at a time.
3. The author should not make any changes:
   • When a reviewer is assigned.
   • Between the junior and senior reviews.

[J0ris-K]

If we put some string in url instead of numbers, it returns NaN
see : image

[ByScripts]

In my opinion, special cases should be dealt with when they are legitimate 'for example, an invalid object ID in the URL would be legitimate if the object has been deleted meanwhile).

But replacing ?foo.idx=3 with ?foo.idx=whatever in the URL by hand is not legitimate.

What I mean is that there will never be a case where it's possible for this to happen, other than by the voluntary action of the user.

It could be interesting to discuss this further with the rest of the team.

[J0ris-K]

Yes I completely agree with you, but the problem for me is that visually it says NaN, so it's weird for user

[OlivierFL]

Any thoughts on this @MathieuRA @pdonias @S3bastianCZ?

[pdonias]

In my opinion:

• validate/convert the query param (prefer +n instead of parseInt(n, 10) as its behavior is less surprising with strings like '42foo')
• if the param is a valid number, use it. Otherwise behave as if the param hadn't been passed at all

[S3bastianCZ]

Maybe something like this to have a fallback to 0 if the value is Nan ?

const startIndex = useRouteQuery<number>(`${id}.idx`, {
  defaultQuery: '0',
  toData: value => {
    const parsed = parseInt(value, 10)
    return isNaN(parsed) ? 0 : toStartIndex(parsed)
  },
  toQuery: value => toStartIndex(value).toString(10),
})

[ByScripts]

I updated toStartIndex to accept string | number and to use +n instead of using parseInt

Invalid values (NaN) will become 0