Is your feature request related to a problem? Please describe.

This issue is part of a review on the naming, structure, and composition of the UI components as brought up in #16367

Link vs Button

Please see this comment on how the link vs button discussion relates to this component library audit: #7534 (comment)

Button

Audit

Opportunities I came across while reviewing this component.

• There is no "Secondary" button, which is confusing because there is Primary and Tertiary.
• It appears that there is no default button (without props) but there is a Default button prop. Also confusing because it's actually the Secondary button style.
• I expected to be able to add an icon to this component (i.e. icon + text), which is a common pattern found in component libraries. I thought IconButton might be able to help, but it's icon-only.
• The isLink prop was confusing and problematic for me. Does it just style it as a link or does it actually use an anchor tag like in other component libraries?

Grouping

I expect Buttons to be a top level category containing several components including, but not limited to, ClipboardButton, IconButton, ButtonGroup, etc.

Suggestions

• Add option to display an icon. We'll need the ability to add a right aligned icon that indicate forward motion.
• Make the isDefault button style actually the default in the component. (e.g. <Button>Button</Button>). Even if it's not named "Default" it's still a good default style for the component. Other styles are used only if a button requires more or less importance.
• Remove isLink in favor of the Tertiary style since they look very similar (assuming there is no functional change). This makes more sense if we add a new Link component.
• Related to the above, if "href" is present, the component should use an anchor element instead of a button element.
• Improve naming. Each convention has its disadvantages. A disadvantage of semantic naming (our current approach) is that sometimes the primary action in a component might not use the Primary button style (e.g. a card might use the Default button for the primary action and the Tertiary button for the secondary action. Here are some options:
  • Primary, Secondary, Tertiary
  • Primary, Default, Minimal
  • Primary, Basic (or Default), Plain
  • Contained, Outlined, Text

IconButton

Audit

Opportunities I came across while reviewing this component.

• I wasn't sure what to expect based on the name of the component. I wasn't sure if it would be a icon + text button or an icon-only button component.
• There doesn't seem to be any toggle functionality in the component. For example, toggling an empty heart icon into a filled heart icon.

Grouping

I expect IconButton to live in a Buttons category, instead of a top level item.

Suggestions

• Add toggle functionality since it's a common pattern in component libraries.
• Based on this effort to show text labels for icon buttons, there seems to be less difference between IconButton and Button.

Two options for Button and IconButton:

1. Keep Button and IconButton separate components

Now that it seems like both components will have text and icon options in the component, here would be the main differences:

• They handle the text label differently. Button is primarily for text (with an option for a supplementary icon) and IconButton is primarily for an Icon (with an option for supplementary text).
• For IconButton, text is hidden by default. When text is shown, it’s centered underneath the icon. When text is not shown, it's visible as a hover tooltip. There's always an icon shown.
• For Button, text is shown by default. There's always text shown. When an icon is shown, it's aligned to the left. There's no need for a tooltip because the text is always shown.
• We simplify the components by automatically handling the text label. The label is always the same whether it's shown or not. The components automatically handles the tooltip.
• We can consider renaming Button to TextButton.

2. Combine Button and IconButton

It could be a simpler experience for designers/developers if we combined the two components. Here is an example of a component library that does this.

The main advantage is that the user of the system won't have to figure out which component to use, since it's all-in-one. The disadvantage is that it might be complex figuring out the different props, and the combination of certain props (e.g. isPrimary + isIconOnly). We might have to split the two components for technical reasons.

Feedback

The feedback I'm looking for is related to naming, structure, and composition. I'm not looking for visual feedback of the components. Prop audit can be seen in the comment below.

• What do you think of combining the two components?
• Have you encountered a successful naming convention for buttons (primary, secondary, etc.)?
• Have any additional thoughts on the isLink prop?