render function for Pagination to support fully custom pagination component

What problem does this feature solve?

Providing a mechanism to allow the consumer to provider their own pagination component, allows the consumer to have maximum flexibility for the styling and functionality of the pagination without sacrificing any quality. The reason why we want to use our own custom pagination is that an external accessibility auditor found 12 different a11y defects in the AntD pagination. It’s faster for our team to build our own accessible pagination than it is to fix rc-pagination.

This change to the table prop interface would provide quality because it would ensure that any automated tests that live within AntD are guaranteed to work with more complex scenarios such as filtering and sorting.

To put this another way, my company’s team will submit the PR for this and we will include the following Jest tests that have identical expectations but that are instantiated with different setups (i.e. these new tests will have the custom pagination component):

1. https://github.com/ant-design/ant-design/blob/ad7df076803163b10117a0e0dc7b0cc7fd6c496b/components/table/tests/Table.filter.test.js#L1278
2. https://github.com/ant-design/ant-design/blob/ad7df076803163b10117a0e0dc7b0cc7fd6c496b/components/table/tests/Table.filter.test.js#L1307
3. https://github.com/ant-design/ant-design/blob/ad7df076803163b10117a0e0dc7b0cc7fd6c496b/components/table/tests/Table.filter.test.js#L1554
4. https://github.com/ant-design/ant-design/blob/ad7df076803163b10117a0e0dc7b0cc7fd6c496b/components/table/tests/Table.filter.test.js#L1642
5. https://github.com/ant-design/ant-design/blob/ad7df076803163b10117a0e0dc7b0cc7fd6c496b/components/table/tests/Table.filter.test.js#L551
6. https://github.com/ant-design/ant-design/blob/ad7df076803163b10117a0e0dc7b0cc7fd6c496b/components/table/tests/Table.sorter.test.js#L714
7. We might want additional test scenarios for sorting since I didn’t find many that tested pagination within the Table.sorter.test.js file

I believe that this will provide substantial quality improvements over the currently recommended approach which is to create a higher component that sets pagination to false and then just handles the pagination re-rendering when onChange is called. Without these automated tests living in the AntD repo, anyone who uses the higher component approach risks having a breakage when AntD changes it’s functionality.

Moreover, I think that this feature will allow consumers to implement the functionality that they’ve asked for in the following PRs by writing their own pagination. Examples of PRs that this feature would unblock are: https://github.com/ant-design/ant-design/issues/10044, https://github.com/ant-design/ant-design/issues/32517, https://github.com/ant-design/ant-design/issues/28413, https://github.com/ant-design/ant-design/issues/28022, https://github.com/ant-design/ant-design/issues/17782, https://github.com/ant-design/ant-design/issues/32119, and countless other pagination requested features.

Due to this approach of flexibility and high automation coverage, my team and I feel that this approach will speed up the consumer’s workload without sacrificing AntD’s progress.

What does the proposed API look like?

So pagination prop in the TableProps interface would be changed to:

pagination?: false | TablePaginationConfig | (page: number, pageSize: number) => React.ReactNode

Please accept that solution since the alternative solution is quite awkward. That awkward alternative involves using itemRenderer, showTotal, selectComponentClass and has the following problematic aspects:

• After using those 3 render functions you are not utilizing any of the functionality of rc-pagination and yet you have to pay the performance cost of rc-pagination’s rendering.
• Those 3 props are not documented on the website and require a great deal of research to discover.
• If those props are ever removed or changed, it would cause a great deal of pain for our teams since our code will come to utilize them heavily.

[mellis481]

Just to add to what value this proposal has, the following are current accessibility issues/defects that the Pagination component has which could be resolved by allowing for a fully custom pagination component:

• The programmatic label for all pager buttons uses the title attribute which is sub-optimal. aria-label is the best attribute to use as it works with more screen readers.
• The programmatic label for page number pager buttons only includes the page number itself and cannot be changed so screen readers will only ever announce eg. “2” instead of something more helpful like “Page 2”.
• Since a pagination component includes navigation elements, it should be wrapped in a nav element with appropriate programmatic label (eg. <nav aria-label=”pagination”>).
• Instead of having the focusable/actionable pager elements be the anchor or button within each <li> element, the focusable elements in the Pagination component are the <li> elements. This results in the following issues:
  • a suboptimal screen reader UX because, when an element is focused, a screen reader will announce “clickable item 2” instead of something more helpful like “page 2 link”.
  • the focusable element is only actionable via the ENTER key only rather than the SPACE and ENTER keys.
  • using UP/DOWN keys has unexpected/undesirable results.

[mellis481]

@afc163 Your simple code example works fine for server-side pagination where the consumer has to manage the dataset (the current slice of data) which they supply to the dataSource prop and pagination info (current page, page size) which they necessarily pass in the pagination prop of the Table component.

The problem occurs in a client-side pagination scenario specifically when filtering data. Currently, functionality to slice the data and update pagination info is encapsulated in the Table component. Using your simple example above, I see no easy way to handle when a user defines an onFilter prop for a column when a custom pagination component is used.

Am I missing something? If not, I believe this is exactly what @dgreene1 was trying to avoid: creating a complex, undesirable DX for consumers and/or a maintenance issue (when the Table component inevitably changes in the future).