carbon: Page selector is not suitable for tables with many pages

@tw15egan Sorry for the delay getting back to you – we are slowly working this out in @carbon/ibm-security 😅

The plan is to refactor the Pagination component to be more like “building blocks”, similar to the UIShell for example, so that way folks have several options to deal with this issue:

• Option 1 - do not include a child component we are calling the PageSelector (i.e., the select element that gets REALLY big when you have a bunch of numbers) at all.
• Option 2 - pass a size attribute to the PageSelector to reduce the height of the selector (allow you to scroll within it). This was a proposal originally in https://github.com/carbon-design-system/carbon/pull/4378 but the reviewers weren’t fond of it (understandably so, due to the way it looked) – BUT on our end we are at least going to give people this option.
• Option 3 - allow a number input instead of a select (this is not implemented yet & needs to be added)
• Option 4?? - due to the building blocks style approach here, theoretically a consumer could make their OWN “Page Selector” or whatever the case may be, and then handle these large page numbers in their own way.

Anyway, now the plan is to polish this refactored pagination component – currently called UNSTABLE__Pagination in our library & then propose it back up to Carbon. It would be a breaking change, for sure.

EDIT: our UNSTABLE__Pagination (work in progress) is here: https://ibm-security.carbondesignsystem.com/?path=/story/components-unstable-pagination--default Again I’m still working on the optional number input. But right now you can leave out the select element, if you want, which would help people dealing with a LOT of pages that creates a performance hit.

@asudoh We mentioned a number input solution way back in https://github.com/carbon-design-system/carbon/pull/4378#issuecomment-546019688 and thought a number input would be a good solution for a large number of pages.

Carbon designers haven’t created design specs, @jendowns have you guys already done that for your option 3?

Definitely think Number Input (mobile variant may work best) is the way to go, but also curious how we would handle the error state. Design will need to work that out before we’re able to implement anything, so a draft PR may help to get some eyes on the problem if you have the time 🙏

@jendowns Number input sounds a viable option, if our designers agree. CC @carbon-design-system/design

As #5129 tells, having many <option> for each page causes the problem not only of the vertical size but also of the performance. My $0.02 is providing an option not to render the <select>, we we haven’t implemented such option.

I’m not sure what you mean here? Can you link to a spec / example?

Apologies - you’re right, for some reason the codepen I was using must not have been updating properly as when I was setting size it was still using the dropdown list.

And yes, I do agree that this is not a catch all solution for the large list - that case definitely requires a researched refactor. I just wanted to draw attention in case it influenced a decision on this particular use case (or if documentation could be updated with guidance on the prop that it doesn’t solve the large options problem).