@Sarai-WMDE I discussed table pagination with the DST engineers today and we came up with some more option questions, even beyond what you and I had discussed earlier. One big blocker may be the translatable label thing - this really does demand a solution like the one proposed in T345386, so that users don't have to pass in numerous translated strings that are the same across most projects. Because of this, and the general complexity here, we think pagination should be removed from the MVP scope and tackled as a separate feature post-MVP. I still strong believe that we should build the pagination UI for consistency's sake, and to prevent Codex users from having to replicate it across projects, but I think we should complete the rest of the Table component first, then tackle pagination as a new feature.

What do you think? Happy to chat about this if it helps!

That sounds sensible to me. I wonder if "Simplifying the pagination UI to us as little text/labels as possible" could still have an impact on this decision? My plan was to explore that next.

On the other hand, from the active use cases that the Table component could cover, both Wikifunctions (Abstract Wikipedia) and Global user contributions (Trust & Safety) have a need for (some kind of) table pagination. I guess it will still be possible for them to "compose" a pagination functionality in context (within their instances of the component) following our specifications. Maybe we could provide a custom demo of the table they can follow? This would also serve as a placeholder solution while we figure the internal component out.

In T360154#9662388, @Sarai-WMDE wrote:

I wonder if "Simplifying the pagination UI to us as little text/labels as possible" could still have an impact on this decision? My plan was to explore that next.

Absolutely; I think we should do this exploration first because it will impact the implementation a lot.

On the other hand, from the active use cases that the Table component could cover, both Wikifunctions (Abstract Wikipedia) and Global user contributions (Trust & Safety) have a need for (some kind of) table pagination. I guess it will still be possible for them to "compose" a pagination functionality in context (within their instances of the component) following our specifications. Maybe we could provide a custom demo of the table they can follow? This would also serve as a placeholder solution while we figure the internal component out.

This is a good point, and a reason for us to prioritize building out table pagination in Codex. In the meantime: for Wikifunctions, adding custom pagination to the Vue component via the footer slot would be doable. I'm more concerned about the GUC project, since that would ideally involve us migrating MediaWiki's TablePager to use Codex (the CSS-only version of the Table, I assume). I think we need to evaluate what that would mean, both in terms of design changes to the existing TablePager UI and in terms of effort. cc @mwilliams because we were just chatting about this!

See T361048 for the TablePager evaluation task

@mwilliams @DTorsani-WMF, and I met today to discuss on the most useful version of the Table's pagination for the upcoming use cases (GUC, Metrics Platform, Wishlist, etc.) and we decided on this simplified version based on the one designed by @Sarai-WMDE.

The pagination will consist of the following elements:

• Items per page selector
• Number of items indicator
• Page arrows

Thanks for providing this updated design! I've responded below to the open questions in the task description.

Can the number of rows in the Select to be customizable by whoever is implementing the table?

I don't think it should be. IMO, this is something we should curate and automate based on research on best practices. I think we should:

• Determine which options to show for a maximum number of results (e.g. the longest list of results we can expect). The list in the design makes sense to me (5, 10, 20, 50, All) - we probably never want to show more than 50 rows in a paged table (more on this below).
• (Maybe) Only show options that make sense. For example, if there are 15 total results, we should not show "50" as an option, since "20" will show all results. If the number of results is unknown, we will just show all options. I'm not really sure if this is necessary, though.

Are there performance concerns at a certain level of rows? e.g. Should we enforce a max?

FWIW, when fetching data from the MediaWiki API, a limit of 50 items is enforced, so 50 seems like a sensible limit. This also appears to be the limit in TablePager.

Is it possible to only show the text "rows" once, for the selected amount so we don't repeat it for every option?

Yes, this is possible with our Select component.

Can the usage of this pagination be optional?

Yes - users will be able to turn on the default pagination we build into the Table component, or add their own custom pagination using the Table component's #footer slot.

In T360154#9727005, @AnneT wrote:

Thanks for providing this updated design! I've responded below to the open questions in the task description.

Can the number of rows in the Select to be customizable by whoever is implementing the table?

I don't think it should be. IMO, this is something we should curate and automate based on research on best practices. I think we should:

• Determine which options to show for a maximum number of results (e.g. the longest list of results we can expect). The list in the design makes sense to me (5, 10, 20, 50, All) - we probably never want to show more than 50 rows in a paged table (more on this below).
• (Maybe) Only show options that make sense. For example, if there are 15 total results, we should not show "50" as an option, since "20" will show all results. If the number of results is unknown, we will just show all options. I'm not really sure if this is necessary, though.

@AnneT it makes sense, we could use this "5, 10, 20, 50, All" logic and adjust it based on the number of rows. This would involve removing unnecessary numbers and always displaying options up to the number of rows below it. For example, if the table has 19 rows, the selection would be "5, 10, All".