Link Buttons

[ashleynolan]

I wanted to discuss something that has come up recently that we've tackled as part of previous projects – but I wanted to get a consensus among the team over which approach would be best and to give people the opportunity to share their opinion.

Problem Outline

We currently have two components; pie-button and pie-link. As you may suspect, pie-button handles the display and functionality of buttons, and pie-link handles the display and functionality of links.

A common pattern in design is to use what looks like a link, but semantically in HTML should function as a button. An example of this can be found in numerous places across JET platforms, but to take one recent example, our redesigned cookie banner also displays this pattern as shown below by the "Manage Preferences" button. This look like a link, but functionally, it opens a modal and so semantically should use a button tag.

So the question really is, how and where should we cater for this in our PIE component library?

Proposed solutions

Here are the solutions I can think of for this. I'll outline my preferred approach after discussing each in turn:

1. Extend pie-button

This solution extends pie-button to include a link variant. This then styles the button to replicate a link, replicating the style of pie-link through this prop.

We currently take this approach in the Fozzie Vue Components:

• Fozzie button link example

Pro's

• pie-button includes all the necessary a11y labels and helpers built into the button component.
• Button Action Types. If a consumer one day wants to set a button link to type="reset", pie-button is already setup to handle this.

Con's

• It's debatable how intuitive this would be for consumers. As the visual design looks like a link, consumers may be inclined to look at the link component first (see proposed solution 2 as an alternative)
• We would need to handle style duplication. The styles for link already exist in pie-link, so we'd likely need to abstract these out into pie-css as a mixin so that they could be shared between both pie-button and pie-link.
• Potentially a lot of unnecessary props to handle. The button link wouldn't support pie-button props like optional icons, loading states, sizes that aren't relevant for link styling. We would likely need to validate against these to ensure there weren't clashes between use of the button link and these unneeded props.

2. Extend pie-link

This solution extends pie-link. This could be done by including a tag prop, which accepts button as a valid option (with the default being a.

Setting this prop to button would then change the pie-link to use a button HTML tag, while still replicating the style of pie-link.

A similar approach is used currently in the Snacks component library:

• Snacks link component usage example

Pro's

• No duplication of styles. Link styling already exists as part of pie-link, so there isn't any issue with needing them elsewhere
• Complete assumption, but it may be more logical to consumers to look first at the link component for a button link, because it stylistically looks like a link.
• No unnecessary stylistic props – stylistic props for pie-link should all be available for this button variant.

Cons

• Will need to consider catering for use cases such as when consumers want to set the button type to reset (could we just allow a type to be passed onto the link tag potentially and validate it?)
• Would need to ensure that any a11y considerations of pie-button are replicated when button tags are used with pie-link.
• Some unnecessary functional props – href, target, rel props not needed by a button, so will need to make sure they play nicely when pie-link tag is set to button.

3. New component pie-linkButton/pie-buttonLink (insert best name here 😆 )

The other potential option is to create a new component that just focuses on this use case as something that looks like a link, but is semantically a button.

Pro's

• No unnecessary props – does just what it needs to do. So wouldn't need to handle any props that aren't needed between links and buttons.

Cons

• We would need to handle style duplication. The styles for link already exist in pie-link, so we'd likely need to abstract these out into pie-css as a mixin so that they could be shared between both pie-link and this new component.
• Potential for functional duplication. Many of the props used in this component would be the same as those used in pie-link (such as size, variant, isBold, isStandalone). We could likely abstract these out to be shared between the two components, but this may add a level of complication in terms of component architecture.
• Would also need to duplicate any a11y considerations handled by pie-button for this link-button component.
• May not be obvious to consumers that there's a whole separate component for this. This use case isn't documented in design, because it's an engineering issue. This leads me to think that consumers would look at the pie-link component before expecting a completely separate component to exist.

Preferred Approach

My own preference is Solution 2. Although I think there will be some things we'll need to handle from having a button tag in pie-link, I don't think it overcomplicates the component.

I also think it makes more sense (to me at least, and likely to those looking first at Figma and then to our component library) to look at the link component and then semantically want to make that component a button, rather than the alternatives. I think having a completely separate component is perhaps overkill, while also creating a component that doesn't exists in the design library, so adds the potential for more confusion.

Thoughts?

It would be great to hear your thoughts, either to support one of the above solutions or if you have a solution I've not thought of, feel free to reply detailing it.

[kevinrodrigues]

@ashleynolan Thanks for putting this together 🎖️

I prefer approach 2 I think this makes the most amount of sense to me.

[sebastienrocks]

Thanks for the write-up Ash.

My say would be the second approach as well. Approach 1 could work, but seeing the pros/cons, 2 seems like the more logical solution.

[LTurns]

Thank you for this 😄 I like 2 the most too

[dandel10n]

Hello, I would vote for the second approach as well as the most straight-forward from both our and consumers perspective.

[jamieomaguire]

Thanks @ashleynolan! I am also happy with approach 2 :)

[maledr5]

Thanks @ashleynolan for opening the discussion. Also I lean for option 2 ✅
It is an interesting conversation that may come back if ever we need links to look like CTA/Buttons. In which case probably the same will apply, and that should be implemented by extending the button component.

I think that semantics connect to how things look as patterns for users to look for. For example, if I see a link style most of the times I would interpret that as a navigation action. Hopefully use cases where links are used functionally, or buttons for navigation, are the exception and not the norm :)