Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not possible to disable Pagination pagesize input #6055

Closed
1 of 2 tasks
bjornalm opened this issue May 11, 2020 · 7 comments · Fixed by #6070
Closed
1 of 2 tasks

Not possible to disable Pagination pagesize input #6055

bjornalm opened this issue May 11, 2020 · 7 comments · Fixed by #6070

Comments

@bjornalm
Copy link

Title line template: [Title]: Brief description

There is no prop to disable selection of a new page size.

What package(s) are you using?

  • carbon-components
  • carbon-components-react

Detailed description

The bug is in the Pagination component. There is no prop to disable selection of a new page size. The pageInputDisabled prop only disables the input for selecting a predefined page, it does not disable the input for defining/selecting a new page size, hence it is not possible to completely disable the Pagination component.

Steps to reproduce the issue

  1. Set both pageInputDisabled and the general prop disabled to be true.
  2. Notice how the page size input is still enabled
@nictownsend
Copy link
Contributor

nictownsend commented May 11, 2020

If you set prop pageSizes=[<single-option>] does it not effectively disable that input? You could then re-enable it with the right sizes conditionally?

@bjornalm
Copy link
Author

bjornalm commented May 11, 2020

If you set prop pageSizes=[<single-option>] does it not effectively disable that input? You could then re-enable it with the right sizes conditionally?

@nictownsend Thanks for your reply. That would indeed prevent the user from selecting a new page size, but it doesn't actually disable the input. It would look like this where the user could still interact with the input:

image

@nictownsend
Copy link
Contributor

True - semantically then I think this is a feature request, as the component has behaved that way consistently. Out of interest, what's the use case for disabling it - is it because changing it might cause a new request from browser you want to stop?

@bjornalm
Copy link
Author

True - semantically then I think this is a feature request, as the component has behaved that way consistently. Out of interest, what's the use case for disabling it - is it because changing it might cause a new request from browser you want to stop?

I'm working with the carbon-addons-iot-react team on a new feature and we need the Pagination to be completely disabled when editing a table (one reason is the one you mentioned).

The pagination component does have a disable and a pageInputDisable prop and I would expect there to be a way to consistently disable the complete pagination component, but indeed, this could also be seen a feature request.

@tw15egan
Copy link
Collaborator

@bjornalm @nictownsend @carbon-design-system/design

Would you expect the disabled prop to disable all elements on the Pagination component, or would there be a circumstance where you would only want to disable certain parts of the Pagination component?

Trying to determine if we need to

  1. Add a new prop (pageSizeInputDisabled)
  2. Tie disabling the page size input to the existing prop that disables the page selection input (pageInputDisabled)
  3. Just tie all 3 of these disabled states under the general disabled prop

I think option 3 would be the easiest, but I'm unsure if there are use cases where we need to leave some items enabled.

@nictownsend
Copy link
Contributor

Personally, option 3 works for me - if you're stopping people changing pages, it seems sensible to stop them changing page size too, as it somewhat equates to a pagination action (go from one page of 10 to showing 10 pages of 10).

I'd say it depends on the use case for disabled in general - I'm personally struggling to see why you would stop a user changing page, but allow them to change the page size.

@bjornalm
Copy link
Author

bjornalm commented May 28, 2020

In my particular case option 3 would work fine, and I think that would make most sense from an API/design perspective but perhaps there is a solid use case for keeping them separated that I can't think of.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants