fix(pagination): add pageSizeInputDisabled prop to Pagination

[tw15egan]

Closes #6055

This PR now ties all Pagination inputs / buttons to the disabled prop, rather than having 3 separate props ton control them individually. This also deprecates the pageInputDisabled prop.

Changelog

Changed

• disabled prop now controls both select elements, as well as the back and forward buttons.
• pageInputDisabled prop now will throw depraction warnings

Testing / Reviewing

Go to Pagination, enable the disabled prop, and make sure all inputs are disabled

[netlify]

Deploy preview for carbon-elements ready!

Built with commit b75639c

https://deploy-preview-6070--carbon-elements.netlify.app

[netlify]

Deploy preview for carbon-components-react ready!

Built with commit b75639c

https://deploy-preview-6070--carbon-components-react.netlify.app

[aagonzales]

Looks good to me 👍

[emyarod]

the prop name in the knobs section is the same as the other input knob

[joshblack]

Looks great after Andrew's suggestions above!

[tw15egan]

@emyarod good catch, updated 👍

[emyarod]

are there instances where each input is disabled separately from the others or should the logic be combined for certain component states?

[tw15egan]

I'm not sure of the total use cases when the pagination is disabled, so I didn't want to combine any of the disabling in case they are used in different scenarios.

I think eventually we may want to go that route, but might be best to wait until v11 and have them all use the disabled attribute?

[emyarod]

just looking for clarification on the component usage before adding the extra prop, since if it is supposed to just be linked with the regular disabled prop we would be adding in a new prop now and then deprecating it in v11 right?

[joshblack]

bump @tw15egan if you have a sec to respond to the last comment 👀

[tw15egan]

I don't have any insight into that, but if you think we should just tie the disabled states together I'm fine with that 👍

[emyarod]

yeah, similar to #6112 (comment) I think if the disabled states are meant to be linked then it makes sense not to expand the API surface area

[tw15egan]

@emyarod @joshblack @aagonzales I updated this PR to tie all inputs to the disabled prop and added a deprecation warning to pageInputDisabled prop.

[aagonzales]

Cool, yeah I'm not sure how people are using the disabled features with pagination. But one way to find out is to change this and see if anyone complains. I think it should be fine though I can't really image why some might be disabled but not others. Seems like products would use this disabled feature mostly for when there isn't any page to paginate to.

[tw15egan]

@aagonzales agreed, I reached out to the original issue creator and they agreed with that assumption as well

#6055 (comment)

[emyarod]

looks good to me

[s100]

Following this change, it seems like it's now impossible to use <Pagination> without raising a deprecation warning. If we set the pageInputDisabled prop to true or false, we get the warning. If we set it to null or undefined, or omit it entirely, it defaults to false and we get the warning. This is a problem for us because our unit tests fail if warnings or errors are raised. Any suggestions?