-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Button: deprecate isPrimary
, isSecondary
, isTertiary
and isLink
props in favour of variant
prop
#31713
Button: deprecate isPrimary
, isSecondary
, isTertiary
and isLink
props in favour of variant
prop
#31713
Conversation
isPrimary
, isSecondary
and isTertiary
props in favour of variant
propisPrimary
, isSecondary
, isTertiary
and isLink
props in favour of variant
prop
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.
I like this a lot!
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.
Once this is rebased it LGTM, nice work.
@youknowriad any ideas when we would be able to actually add deprecation warnings for the old props?
Right after 5.8 beta freeze would work for me. I guess that means next week :) |
@@ -46,8 +46,7 @@ export default function DeleteTemplate() { | |||
<MenuGroup className="edit-post-template-top-area__second-menu-group"> | |||
<MenuItem | |||
isDestructive | |||
isTertiary | |||
isLink | |||
variant="tertiary" |
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.
Hey @jorgefilipecosta , we are currently in the process of replacing isTertiary
and isLink
with a new variant
prop — which also means that a button can be assigned to only one variant at the time.
Does this fit your needs? Or did you need this button to be at the same tertiary AND marked as a link?
We're also considering keeping isLink
(see #31713 (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.
The design is changed a little bit. I think it is ok (provided we correct a small pixel alignment between the button and the input as a follow up):
new:
But I'm going to cc: @jameskoster to double-check if we can do this UI change.
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.
I could also change it to variant="link"
if that works better
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.
Should be fine, I actually have a PR open to adjust that popover a bit. There it's only using isSecondary
and isDestructive
which I assume will work fine with the new system?
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.
There it's only using isSecondary and isDestructive which I assume will work fine with the new system?
That's not going to be an issue. isSecondary
will become variant="secondary"
and isDestructive
can stay as-is
@@ -88,7 +88,7 @@ const ModifiedWarning = ( { originalBlock, ...props } ) => { | |||
originalBlock.title || originalName | |||
); | |||
actions.push( | |||
<Button key="convert" onClick={ convertToHTML } isLink> | |||
<Button key="convert" onClick={ convertToHTML } variant="link"> |
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.
Wonder if it's slightly odd to see link
as a variant. Would it ever make sense to have a "primary link" or a "secondary link"? Should externalLink
be considered a variant as well (it exists as a separate thin now)?
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.
variant="link"
doesn't determine whether the component renders an anchor
tag, that's determined by the href
prop's presence.
Furthermore, the link variant cannot be mixed with the other three variants for a good looking experience. These are the three variants together with link
:
They all say "tertiary" button but they're the mixes of link with tertiary, secondary and primary respectively.
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.
If it's determined by href
why do we need it as a variant?
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.
link
is a variant of the style of the button, not the functionality. Passing href
changes the functionality. You could, for example, have a button
that looks like a link by passing <Button onClick={() => alert('hello!')} variant="link">Hello!</Button>
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.
We should probably rename it to text
or flat
though. material-ui
is a good source of inspiration for this. (not necessary related to this PR though)
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.
I'd expect text
to look most like the variantless button though, i.e., without the underline. 🤷♀️ I'm fine renaming it to whatever makes the most sense to people but I don't think we'll find something perfect. Our variants aren't as "varied" as material's. We really just have the five: no variant
, primary
, secondary
, tertiary
, and link
. And they all or remove the outline/background arbitrarily (link
, incidentally, is probably the easiest to guess what it does currently aside from the confusion around functionality).
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.
I agree. I think it would be best to merge this change (i.e. introducing variant as a preferred alternative to the overlapping is
props) and then we could potentially reconsider renaming or changing variants separately. Don't want to keep this PR open any longer because it touches so many usages of Button that it needs constant rebasing, etc.
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.
It's weird to use "link" to refer to an appearance characteristic but we can revisit this separately as we should also clarify the design expectations.
I like this.
This sounds like a good approach to me. I think we might consider soft deprecating — just converting internally but not warning — given how widespread the use of this component is. |
…/deprecated`, move new tests into one file
This change is introduced in the docs too early. WordPress 5.8.1 still uses button with is**** attributes, and these deprecations (will still work in future versions - I inspected code) are not mentioned at all in the docs for Button component |
Hey @Lovor01!
This deprecation was mentioned in the changelog. Regarding the mention on the
Could you be more precise about which Buttons in the codebase you are referring to? |
We use variant instead, since WordPress/gutenberg#31713
Description
This PR takes inspiration from previous PRs #29990 and #31297
variant
prop (i.e.variant="primary|secondary|tertiary|link"
)isPrimary
,isSecondary
,isTertiary
andisLink
props as deprecated yet, but add logic to the<Button />
component to translate their values into thevariant
propvariant
prop instead of the deprecated props (necessary to have all tests passing)Part of the next steps highlighted in #30503
Testing instructions
npm run test-unit packages/components/src/button
npm run storybook:dev
and compare the Button component against what's currently in productionisPrimary
,isSecondary
,isTertiary
andisLink
props and make sure they have all been replaced with the newvariant
propScreenshots
N/A
Types of changes
Checklist:
*.native.js
files for terms that need renaming or removal).