-
Notifications
You must be signed in to change notification settings - Fork 4.7k
ToolbarButton: Deprecate isDisabled prop and merge with disabled
#63101
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
Conversation
# Conflicts: # packages/components/src/toolbar/toolbar-button/index.tsx
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +6 B (0%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
ciampo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
One thing that I noticed while testing is that, if I pass disabled and __experimentalIsFocusable to ToolbarButton, the disabled button is still skipped when using arrow keys, but is not skipped when using the Tab key.
| // TODO: Possible bug; maybe use onClick instead of props.onClick. | ||
| if ( props.onClick ) { | ||
| props.onClick( event ); | ||
| // TODO: Possible bug; maybe use onClick instead of restProps.onClick. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated, but what is this comment about? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The onClick function written here will be overridden by the consumer's onClick function passed through with the restProps 🙃
Good catch 😳 I confirmed this also happens in trunk, but I think it will be normalized by #63102. |
…ordPress#63101) * ToolbarButton: Deprecate `isDisabled` prop and merge with `disabled` # Conflicts: # packages/components/src/toolbar/toolbar-button/index.tsx * Migrate `isDisabled` usage in codebase * Add changelog Co-authored-by: mirka <[email protected]> Co-authored-by: ciampo <[email protected]>
Follow-up to #62306 (comment)
Fixes #63070
What?
Deprecates the
isDisabledprop onToolbarButtonand merges it intodisabled.Why?
ToolbarButton accepts both
isDisabledanddisabledprops to disable the button, and can result in slightly different behavior between the two, especially when wanting to achieve a focusable disabled button (see details in #63070).Current API usage in our codebase shows that most people reach for the
disabledprop. I could also find no meaningful significance for theisDisabledprop to be there (original PR where it was introduced).How?
Passive deprecate
isDisabledand alias it todisabled.Testing Instructions
Play around with the Storybook code for the
ToolbarButtons in theToolbarstory. PassingisDisabledshould result in the same behavior as passingdisabled, especially in combination with accessible disabled props like__experimentalIsFocusableoraccessibleWhenDisabled.