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

Button: deprecate isPrimary, isSecondary, isTertiary and isLink props in favour of variant prop #31713

Merged
merged 17 commits into from
May 26, 2021
Merged

Button: deprecate isPrimary, isSecondary, isTertiary and isLink props in favour of variant prop #31713

merged 17 commits into from
May 26, 2021

Conversation

ciampo
Copy link
Contributor

@ciampo ciampo commented May 11, 2021

Description

This PR takes inspiration from previous PRs #29990 and #31297

  • Expose a new variant prop (i.e. variant="primary|secondary|tertiary|link")
  • Do not mark the isPrimary, isSecondary, isTertiary and isLink props as deprecated yet, but add logic to the <Button /> component to translate their values into the variant prop
  • Update docs, changelog, unit tests and Storybook Button stories
  • Add unit tests to verify that the above-mentioned props are effectively marked as deprecated, while the expected classes are still being applied
  • Update all of the usages in the repo to utilise the new variant prop instead of the deprecated props (necessary to have all tests passing)

Part of the next steps highlighted in #30503

Testing instructions

  • Run Gutenberg and make sure that Buttons still work as expected
  • All tests are passing
  • Run Button unit tests: npm run test-unit packages/components/src/button
  • Run local storybook npm run storybook:dev and compare the Button component against what's currently in production
  • Search in the repo's codebase for the isPrimary, isSecondary, isTertiary and isLink props and make sure they have all been replaced with the new variant prop

Screenshots

N/A

Types of changes

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • I've tested my changes with keyboard and screen readers.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • N/A I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

@ciampo ciampo changed the title Button: deprecate isPrimary, isSecondary and isTertiary props in favour of variant prop Button: deprecate isPrimary, isSecondary, isTertiary and isLink props in favour of variant prop May 11, 2021
Copy link
Member

@kevin940726 kevin940726 left a 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!

packages/components/src/button/test/deprecated-props.js Outdated Show resolved Hide resolved
packages/components/src/button/test/deprecated-props.js Outdated Show resolved Hide resolved
packages/components/src/placeholder/style.scss Outdated Show resolved Hide resolved
@ciampo ciampo requested a review from getdave as a code owner May 14, 2021 08:22
@ciampo
Copy link
Contributor Author

ciampo commented May 14, 2021

Rebased on top of latest trunk, and removed the official deprecation notices in 8344c80.

The docs don't mention the isPrimary, isSecondary, isTertiary and isLink props anymore, in favor of the new variant prop

Copy link
Contributor

@sarayourfriend sarayourfriend left a 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?

@youknowriad
Copy link
Contributor

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"
Copy link
Contributor Author

@ciampo ciampo May 20, 2021

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))

Copy link
Member

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:
detele button new

old:
button-old

But I'm going to cc: @jameskoster to double-check if we can do this UI change.

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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

@ciampo ciampo self-assigned this May 20, 2021
@ciampo ciampo added [Feature] Component System WordPress component system [Package] Components /packages/components [Type] Code Quality Issues or PRs that relate to code quality labels May 20, 2021
@@ -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">
Copy link
Member

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)?

Copy link
Contributor

@sarayourfriend sarayourfriend May 21, 2021

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:

Captura de Tela 2021-05-21 às 06 48 34

Captura de Tela 2021-05-21 às 06 48 22

Captura de Tela 2021-05-21 às 06 48 04

They all say "tertiary" button but they're the mixes of link with tertiary, secondary and primary respectively.

Copy link
Member

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?

Copy link
Contributor

@sarayourfriend sarayourfriend May 21, 2021

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>

Copy link
Member

@kevin940726 kevin940726 May 24, 2021

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)

Copy link
Contributor

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).

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.

Copy link
Member

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.

@mtias
Copy link
Member

mtias commented May 20, 2021

I like this.

Do not mark the isPrimary, isSecondary, isTertiary and isLink props as deprecated yet, but add logic to the component to translate their values into the variant prop

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.

@ciampo ciampo merged commit 9df736c into WordPress:trunk May 26, 2021
@ciampo ciampo deleted the feat/components-button-variant-deprecation branch May 26, 2021 14:36
@github-actions github-actions bot added this to the Gutenberg 10.8 milestone May 26, 2021
@Lovor01
Copy link
Contributor

Lovor01 commented Oct 25, 2021

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

@ciampo
Copy link
Contributor Author

ciampo commented Nov 9, 2021

Hey @Lovor01!

This change is introduced in the docs too early [...] these deprecations are not mentioned at all in the docs for Button component

This deprecation was mentioned in the changelog.

Regarding the mention on the Button docs, we are on purpose not mentioning it. We just removed the props from the docs (while still supporting them in code), in order to encourage the usage of the new variant prop without introducing a breaking change. You can read more about this approach in the contributing guidelines

WordPress 5.8.1 still uses button with is**** attributes

Could you be more precise about which Buttons in the codebase you are referring to?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Component System WordPress component system [Package] Components /packages/components [Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants