guardian / source

Source: a component library for the Guardian's Design System

Source

A component library for the Guardian's Source Design System.

Source packages have moved to https://github.com/guardian/csnx in #252.

The last versions to be published from here were:

• @guardian/[email protected]
• @guardian/[email protected]
• @guardian/[email protected]
• @guardian/[email protected]
• @guardian/[email protected]

https://github.com/guardian/source/releases

source's Issues

Blurry `Lines` when zoomed

Describe the bug
As reported by @paperboyo:

Them gradient lines always inconsistent widths on zoom in Firefox
No idea if there is a way of working around this Firefox bug, but they look for me like this more often than not as they are now (always have):

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Desktop (please complete the following information):

• OS: macOS
• Browser: Firefox
• Version: [e.g. 22]

Additional context
Browser is zoomed 115%

Add Toggle switch component to code

Create toggle switch component in Source code.

Document the process and any steps.

https://www.figma.com/file/DBRQVMYX4qwYmXm6NTlUQK/%E2%9C%AD-Toggle-Switch?node-id=1%3A311

There are three styles
1)

Things to be updated
DCR

1. Colour: Use green.400 (On) and neutral.46 (Off)
2. Animation for the tick. The tick should appear at the same time as the circle moves to the right.

Android
1)

iOS
1)

Inclusion of new gift icon

We've had to introduce a new svg gift box icon into the main navigation for "gifting" on frontend and dotcom-rendering, it'd be good to get this in source. Can I just raise a PR to include it?

Field active state should override field error state

See #1156

When field is active, the active border should be applied even if the field is in an error state

Here’s the flow chart for the form elements.
https://www.figma.com/file/4z53aFojeYVSMTpgZQzpDx/Flow-for-interactive-component?node-id=0%3A1

Revert work around for chrome browser

Regarding the issue raised here:
https://github.com/guardian/source/blob/main/src/core/components/radio/styles.ts#L118

it appears that it has been resolved:
https://bugs.chromium.org/p/chromium/issues/detail?id=375693#c88

We should therefore revert back to display: flex.

Note:
The display:block and vertical-align:middle work around did not seem to work for DCR (example below). I will do a workaround in the meantime to force display: flex for the Radio wrapper.

Before Update:

After Update:

Untangling emotion from source-foundations

Background

In some cases, we are exporting Emotion CSS from source-foundations. This goes against the principle that source-foundations should be agnostic as to which css-in-js frameworks it supports.

It also breaks the build for AMP in DCR, because it makes the assumption that some of the CSS we export is not Emotion CSS.

Work done

Original PR that was closed and split into the two below for clarity:
#1554

• Fixes CSS and adds tests to ensure it is valid: #1566
• Proposal for a possible approach to indicate where we export Emotion CSS: #1568

Make tertiary buttons transparent

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

Currently tertiary buttons take an explicitly defined background that happens to be identical to the background colour of the theme in which they ought to be used. For instance, on default theme, the tertiary button has a white background.

Describe the solution you'd like

The background colour of tertiary buttons ought to be transparent, so it can be used on different background colours.

Ideally, the border radius would be 0 to make the button feel more like a link when tabbing

Text input field label should be bold

Describe the bug
The input label should be bold by default

Screenshots

Live example:

(https://www.theguardian.design/2a1e5182b/p/097455-text-input-field/b/050445)

In Figma:

(https://www.figma.com/file/qY0C090LN6LDAqdzmV2FsA/Text-inputs?node-id=7%3A360)

Button text should not wrap

Describe the bug

Button and LinkButton components occupy as much space as they need to, determined by the length of the content and limited by a container. If the space allocated by a container is too small for the label, the text wraps, in a hideous fashion. This serves as a nice reminder that button text should never wrap, but we could present this in a more graceful way, that doesn't totally degrade the user experience.

This issue was spotted and raised by @jeanlauliac 🙇

Expected behavior

Button text should never wrap. The button width should accommodate the length of the label, even if this means breaking out of its container.

This can potentially be achieved using the white-space property.

Screenshots

Current behaviour:

Desired behaviour:

`SvgChevronRightDouble` please!

We already have a chevron right (and left) single but n0 double versions of them

This double svg is already present in DCR but that version isn't easily used with Source (too big)

Back to top link protrudes in footer

Describe the bug

The back to top link sits along the horizontal boundary line of the footer, and as such protrudes outside of the footer bounding box (see screenshot). This looks odd if the container above the footer is not the same colour as the footer itself. This means the footer component is making an assumption about surrounding components, making it less reusable/

Expected behavior

The footer should always be square. The back to top link should not escape from the boundaries of the footer.

Screenshots

Indeteminate checkbox background is black on iOS Safari

Describe the bug
Indeterminate styling looks weird on iOS Safari

Screenshots

Looks like:

Should look more like desktop version:

Fix lint warnings

Describe the bug

typescript-eslint is currently generating 151 warnings on each build. The longer we fail to fix them, the more warnings we will accrus.

To Reproduce

$ git clone [email protected]:guardian/source.git
$ cd source
$ yarn
$ yarn validate

Expected behavior

There should be no warnings

⚠️ Important note

It is not necessary to fix all these warnings in a single PR 😄

Add ChromaticQA

Describe the solution you'd like

DCR has been using ChromaticQA to excellent effect for cross-browser, multi-breakpoint visual regression testing. Since we now have a standard licence, we can start using it in other codebases too. Source will find a lot of benefit from it, especially cross-browser testing.

Font Style Normal

source/src/core/foundations/src/typography/fs.ts

Line 30 in d42e982

italic && requestedFont && requestedFont.hasItalic ? "italic" : ""

As italic is an optional parameter for fonts, there are three states it can be in: true, false and undefined. Should font-style be set explicitly to normal when italic is set explicitly to false? In essence, the following:

true

font-style: italic;

false

font-style: normal;

undefined

""

This is useful for times when you want to explicitly set font-style: normal;. For example, when overriding the user agent italic styles for <address>.

@guardian/src-svgs is missing the esm build

Describe the bug
@guardian/src-svgs dist dir only includes a cjs index.js, but the package declares:

"main": "dist/index.js",
"module": "dist/index.esm.js",

Running yarn build in src/core/svgs does generate the file though.

To Reproduce

1. yarn add @guardian/src-svgs
2. look in node_modules/@guardian/src-svgs/dist

Expected behavior
Both files should exist

cc @ripecosta

Larger Text Sans For Guardian Labs

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

Headlines on Guardian Labs articles appear in a Text Sans font, at a size of 34px (example here). The largest size offered by Source for Text Sans is 24px (see here).

Describe the solution you'd like

A larger Text Sans to be exposed by the typography module, providing a 34px version e.g.:

textSans.xxlarge()

Describe alternatives you've considered

There's also a Guardian Sans Web font that was previously used for sans headlines, but I think we moved away from that (@paperboyo could probably confirm).

Additional context

See the discussion on apps-rendering here.

Tiles layout broken in IE11

Describe the bug

In IE11, a multi-column tile layout looks like a collapsed stack with no margin between tiles

Expected behaviour

Do we could just say that a tile layout is a stack in IE11, and respect y-space between tiles? Or do we fix it so it behaves the same as modern browsers?

Screenshots

IE11

Chrome

Additional context

We could potentially not use CSS Grid. The Columns layout achieves something similar using flex. It's not impossible, just complex.

Release Version 1 of src-foundations to allow major-matching

Is your feature request related to a problem? Please describe.
When installing src-components into consumers, peer dependencies easily fall out of sync because `0.x versioning doesn't match on major - it only exact matches.

For example, DCR's @guardian/src-button dependency is currently is 0.17.0 whereas consent mangement platform is 0.16.1.

This does not match on the major because it's 0.x.

Major versions, however, match upwards on minors and patch.

E.g - React

0. versions

vs

> 0. versions

The concern here is whether you believe the Public API is considered stable? And is it something that can be handled with major bumps and rc releases as you're currently doing?

I would say yes - I'm guessing rc releases are unusual on 0. alpha code as they signify significant public usage - and any release of 0. functionally acts the same as an rc release in the sense that it exact matches when installed.

Describe the solution you'd like
Bump src-foundations and components to 1.x.

Describe alternatives you've considered
Desperately try to keep all the modules and consumers in sync.

Prevent CI action running on both master and gh-pages branches

Describe the bug
Currently the CI action runs on both master and gh-pages branches. This is unnecessary

Expected behavior
Only the Deploy to GitHub Pages action should run on master. We don't need any actions to run explicitly on gh-pages.

Animation overlay span in Checkbox intercepts Selenium click events aimed at the underlying input

Describe the bug
When running our Selenium tests against the Subscriptions checkouts, the tests are failing on Source checkboxes due to the span that provides the tick animation intercepting the click event. An example of a failed test run is here: https://travis-ci.org/github/guardian/support-frontend/builds/750209284

The same behavior appears whether using clickOn or the checkbox(selector).select() methods from ScalaTest. However the problem is fixed if the offending span has pointer-events: none applied, which does not seem to otherwise effect the component in any way.

To Reproduce
Clone support-frontend and rewind to commit 187be8a, then run the Selenium tests with sbt selenium:test. The tests will fail when attempting to check out using direct debit, as the checkbox to confirm that a user is the account holder cannot be clicked.

Expected behavior
The checkbox should be clickable using Selenium in order to verify the expected behaviour of the checkout as a whole.

The fix for this is really tiny- it's just applying pointer-events: none to that span in the Checkbox component- so I'm happy to raise a PR to fix this myself if you'd like!

Allow choice cards to wrap

Describe the bug

If choice cards don't fit into their container, they should wrap onto the next line

To Reproduce

Constrain the width of the container for a set of choice cards. Observe that the cards break out of their container

Expected behavior

The cards should wrap onto the next line. Currently, cards take up 1/n of the available space, where n is the number of choice cards (flex-grow: 1). In order to preserve the widths of each choice card, we would need to switch from using flexbox to using grid to layout the cards.

Screenshots

Currently:

Ideally:

Wide icons should always align with centre of text in Link component

Describe the bug

When overriding the font size in Links with icons, the vertical alignment of the icon is off:

<Link
  icon={<SvgIndent />}
  subdued={true}
  href="#"
  cssOverrides={css`
    ${textSans.xsmall({ fontWeight: "bold" })};
  `}
>
  Reply
</Link>

Expected behavior

Ideally, icons should always align with the centre of the text, even if text is overridden

Additional info

We should move away from relying on this magic number by using flexbox or some other vertical-centre pattern

LinkButton does not support icons

Describe the bug
I can provide the icon and iconSide props to Buttons but they're not supported for LinkButtons

Type '{ children: string; priority: "primary"; size: "small"; iconSide: string; icon: Element; "data-link-name": string; "data-edition": Edition; onClick: () => boolean; }' is not assignable to type 'IntrinsicAttributes & Pick<LinkButtonProps, "css" | "children" | "style" | "title" | "cssOverrides" | "className" | "download" | "href" | ... 260 more ... | "onTransitionEndCapture"> & Partial<...> & Partial<...>'.
  Property 'iconSide' does not exist on type 'IntrinsicAttributes & Pick<LinkButtonProps, "css" | "children" | "style" | "title" | "cssOverrides" | "className" | "download" | "href" | ... 260 more ... | "onTransitionEndCapture"> & Partial<...> & Partial<...>'.ts(2322)

To Reproduce

            import { ThemeProvider } from 'emotion-theming';
            import { Button, buttonReaderRevenueBrand } from '@guardian/src-button';
            import { SvgArrowRightStraight } from '@guardian/src-svgs';
            
            <ThemeProvider theme={buttonReaderRevenueBrand}>
                <LinkButton
                    priority="primary"
                    size="small"
                    showIcon={true}
                    icon={<SvgArrowRightStraight />}
                    data-link-name="nav2 : support-cta"
                    data-edition={edition}
                    href={urls.subscribe}
                >
                    Subscribe
                </LinkButton>
            </ThemeProvider>

Expected behavior
Icons in my link butons pleaseee!

Support success message in TextArea

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

It is not possible to set a success message on the TextArea component. Currently it only supports an error message

Describe the solution you'd like

Similar to TextInput, TextArea ought to support a success message.

React warning on LinkButton: each child should have a key prop

Describe the bug

In Storybook we're seeing the following warning in dev on the link button story (<-- this link only works when running yarn storybook locally)

Warning: Each child in a list should have a unique "key" prop.

Check the render method of `LinkButton`. See https://fb.me/react-warning-keys for more information.
    in div (created by LinkButton)
    in LinkButton
    in div (created by storyFn)
    in div (created by Context.Consumer)
    in EmotionCssPropInternal (created by storyFn)
    in div (created by Context.Consumer)
    in EmotionCssPropInternal (created by storyFn)
    in div (created by storyFn)
    in storyFn
    in ErrorBoundary

I believe this is due to the way we're composing elements using an array (see possible culprit)

Expected behavior

We should pass a key prop to elements composed using arrays, or we should explicitly disable the lint rule for this case.

Enable ref forwarding for leaf components

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

In React, refs provide a reference to the DOM element associated with a React element. However React components cannot directly accept ref props.

Describe the solution you'd like

We need a way to access references to DOM elements associated with instances of Source components. Possible implementations would be:

• Ref forwarding
• Passing a ref prop with a different name (e.g forwardedRef), which gets passed as a ref within the component.

Additional context

This is blocked by an issue at the intersection of forwardRef, defaultProps and TypeScript. (partially fixed and explained here, but this doesn't address the forwardRef case)

Additional icons for apps-rendering

We are still using an icon font in apps-rendering but would like to use the SVG icons in source.

There's some icons missing we would need before fully removing that icons font:

• Camera
• Stars
• Quote
• Comment

I've got a Figma file with these SVGs so I could make a PR to add them, would this be useful?

Full width Radio labels

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

The contributions landing page has this payment method selector

As it stands, I'm not sure if there's a great way to implement this with src-radio? Crucially we want the whole area between the label and the payment icon clickable. Our current solution requires internal knowledge the Radio component and broke when a div swapped for a span (#538)! We'd like a someway of building this in a less hacky way!

Describe the solution you'd like
One potential solution could be something like a fullWidthLabel prop on the Radio component that causes it to fill it's parent width?

Text box field active state does not persist

When you click in a text input box, the outline of the box should be blue while you are in it. Instead, it flashes blue, but then goes grey.

Buttons prop `children` mandatory

Is your feature request related to a problem? Please describe.
Buttons children prop are mandatory, however they should be optional.

Describe the solution you'd like
Make children prop optional.

Remove tooltip prop from ToggleSwitch

The tooltip prop on the toggle switch does nothing currently, should we remove this?

closes #1586

RFC: controlled vs uncontrolled inputs

Uncontrolled

Currently Source input components such as Checkbox and Radio use an uncontrolled approach to state management. The state is stored in the DOM rather than within the React state.

It is not necessary to explicitly set a default value, nor have that value stored in React state.

Consumers of these components can access the state from the DOM in a onChange handler. e.g

<Checkbox
  label="Check me"
  onChange={e => {
    respondToChange(e.target.checked);
  }}
/>

In the uncontrolled approach, a consumer could also access the state using a ref. This is not currently possible as ref forwarding is not enabled on any Source components (see #294).

Controlled

As a shift in approach we could make Source components controlled. This makes React the single source of truth for component state. It forces the consumer to specify an initial state as well as an onChange handler to access the state.

const {isChecked, setChecked} = useState(false)

return (
  <Checkbox
    label="Check me"
    checked={isChecked}
    onChange={e => {
      setChecked(e.target.checked);
    }}
  />
)

React recommend this approach, and it also unlocks more powerful features such as immediate field validation, or forms that allow you to dynamically add or delete form fields.

Request for comments

I'm leaning towards making all our form components controlled, mainly for more powerful features. It means we can provide stricter type enforcement, by insisting on consumers providing a default value and an onChange handler. It helps us work around tricky bugs that surface when you're not sure if React or the DOM is the source of truth for state (cc @twrichards @rBangay)

Does anyone have any opinions, concerns or requests for clarification on this? I'm super interested to hear from you, and especially anyone with experience building React forms, either simple or complex.

Link components with icon do not wrap correctly

Describe the bug

In Link and LinkButton, we use display: inline-flex to pull icons down to the baseline of the link text description. This means long text descriptions with icons don't wrap correctly and sit on a separate line to the surrounding text.

Expected behavior

In Link, at least, the text should wrap correctly.

Screenshots

Current behaviour:

Expected behaviour:

(Note: in the above screenshot, the icon should also be underlined)

Additional context

The correct behaviour is (I believe) impossible to achieve with LinkButton, since button elements cannot be made to appear inline. The workaround is to pass an onClick handler and role="button" to a Link component.

this it not attached to a repo

test

this issue should automatically appear in github.com/orgs/guardian/projects/61 incoming column

Responsive column widths

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

Column widths are not responsive. i.e. it's not possible for a column to take up 1/4 of the container width at desktop, but 1/2 the width at tablet

Describe the solution you'd like

It would be useful (and indeed 🆒) to create an API that handles that

e.g. <Column width={[1, 1/2]}>

Atom components

We've had some discussions about where Atoms could live for dotcom-rendering and apps-rendering and whether they can be shared. Would the design system be a good place to keep atom components?

Possible alternatives:

• Continue developing separately on apps-rendering, dotcom-rendering and maybe editions?
• Share atom components in a different repo/package

I've made a pr to add interactive atoms to apps-rendering but I think other atom types would be easier to make into React components.

RadioGroup allow `supporting` prop to be able to use `ReactNode`

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

In some quizzes on frontend we have a supporting image next to the question (example: https://www.theguardian.com/football/that-1980s-sports-blog/2020/jun/12/sports-quiz-football-in-the-1980s look at question 4).

The best way to render the supporting image would be as part of the RadioGroup component. However there is no way to have text followed by supporting media in the current design.

Describe the solution you'd like

We could change supporting prop on RadioGroup to allow text | ReactNode allowing us to have images or videos as supporting content.

Describe alternatives you've considered

• We could add another prop (suggestion: supportingMedia as a name) to RadioGroup
• We could allow RadioGroup to allows other components other than Radio (not ideal)

RFC: Grids and page layout

The most-requested feature for Source at the moment is support for Guardian's grid layout system. This includes abstractions around:

• common media queries
• the number of columns available at each breakpoint
• the width of columns at each breakpoint
• the width of gutters between columns
• whether a border appears between columns
• horizontal padding around the page container

The abstraction must ensure the layout doesn't look broken in IE11.

Note: this request is not simply about providing a convenient wrapper around CSS Grid. It must consider the Guardian's grids, with the purpose of unifying layout across products.

Approaches

Component-based

We are currently developing a component-based approach with an API that looks like:

import { GridRow, GridItem } from "@guardian/src-grid"

const Article = () => (
    <GridRow breakpoints={["mobile", "tablet", "desktop", "leftCol", "wide"]}>
        <GridItem span={[0, 3, 3, 4, 4]} borderRight={true}>
            <Sidebar />
        </GridItem>
        <GridItem span={[4, 9, 9, 10, 12]}>
            <Main />
        </GridItem>
    </GridRow>
)

See the Grid component API docs for more details.

Pros

• Development is easier as the JSX reflects the layout. This might be useful for maintainers reading existing through code.

Cons

• Adds extra HTML elements to the generated markup which has performance implications
• Makes JSX more verbose when reading, and distracts from the actual content of a component
• See #423 (comment) for very related thoughts

CSS maker functions

An alternative approach uses functions to generate CSS that are included directly in the css tag:

const gridContainer = css`
  ${grid({
    grids: [
      'wide',
      'leftCol',
      'desktop',
      'tablet',
      'mobile'
    ],
  })};
`

const leftColumn = css`
  ${gridItem({
    columns: [
      3, // wide
      2, // leftCol
      3, // desktop
      0, // hide on tablet
      0, // hide on mobile
    ],
    offset: [
      2, // offset 2 columns to the right at wide
      0, // leftCol, don't offset
      0, // desktop, don't offset
      0, // tablet, don't offset
      0, // mobile, don't offset
    ]
  })};
`

Manage Frontend provides a similar approach but with less granular control over breakpoints. DCR uses a a CSS maker approach but using grid-template-columns and grid-template-areas.

Pros

• No extra markup generated
• Portable to non-JSX projects. Feasible to translate into SCSS

Cons

• Perhaps less readable?

Discussion

I would like to open for comments which of these approaches is the most likely to provide the most coherent, maintainable and extensible developer experience without detrimentally affecting the client side performance.

We are not discussing implementation or the exact API at the moment. We can discuss whether either approach unlocks the possibility for a particularly useful API.

I'd love to hear your thoughts 🎉

Also if you have tried out the Grid components provided by Source, please let us know your experience.

Allow checkbox to have supporting text but no label

Describe the solution you'd like
I would like to be able to use the supporting text without having to use a label

Describe alternatives you've considered

I've added a checkbox with a label that simply says "Confirmation", just so I can use the suporting text. This is not ideal

Additional context

See guardian/support-frontend#2391

Allow consumer to visually hide text labels

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

It is not always necessary to visually show a text label above a user input field such as text input field, text area or select box. An example would be when there is a single user input field on the page and there is enough additional context on the page to inform the user what kind of data is required.

Describe the solution you'd like

It should be possible for the consumer of these components to visually hide the text label of a user input field. We could achieve this by expanding the API of our user input field components to include a new prop:

{
  hideLabel: boolean
}

The naming here is consistent with the same feature in the Button component.

By default, this prop is set to false. If set to true, the text label is visually hidden. The text label will still be read by a screen reader.

This solution should be applied to the following components:

• TextInput
• TextArea
• Select
• RadioGroup
• CheckboxGroup

Text input field should have blue outline when active

Describe the bug
Text input field should have blue outline when active

Screenshots

Live example:

(https://www.theguardian.design/2a1e5182b/p/097455-text-input-field/b/050445)

In Figma:

(https://www.figma.com/file/qY0C090LN6LDAqdzmV2FsA/Text-inputs?node-id=575%3A164)

RFC: Layout components

From #488, there was broad agreement in favour of a JSX-based API. I've started spiking a set of layout components.

Abandoning the Grid components

I have moved away from the existing Grid component API for a few reasons:

1. The columns / spans abstraction is confusing and hard to remember. It expects the developer to know how many columns are available at each breakpoint.
2. It provides an unnecessarily high granularity of control, making the API weighty for no good reason.
3. The name "Grid" is confusing and means too many things.
4. It tries (and fails) to be a one-stop solution for all layouts.

Layout spiking

A number of developers and designers have kindly shared layouts that they are currently working on. Over the last few days I've built a number of them, noting layout similarities and patterns.

• Checkout flow
• Consents flow
• Thank you flow
• Article on web
• Showcase in Editions

As a result of this spike, I've identified 5 new layout components that, when combined, can be used to build (nearly) all of these layouts.

• Container
• Stack
• Columns / Column
• Tiles
• Hide

This work has been greatly inspired by awesome open source component libraries such as Braid and Chakra-UI.

Container

<Container>
  <article></article>
</Container>

The Container centres the page content and applies a width that corresponds to the grid at the current breakpoint.

Stack

<Stack>
  <div></div>
  <div></div>
  <div></div>
</Stack>

Children will be stacked one on top of the other.

Columns / Column

<Columns>
  <Column width={1/4}></Column>
  <Column width={1/4}></Column>
  <Column></Column>
</Columns>

Columns will be arranged side by side on a single row, with the specified width.

width: If no value is provided, the column width will be fluid (i.e. take up remaining space, divided between all fluid columns).

Tiles

<Tiles columns={3}>
  <div></div>
  <div></div>
  <div></div>
  <div></div>
</Tiles>

Items will be arranged with equal width and spacing with the specified number of columns, wrapping onto a new row as necessary.

Hide

<Hide above="tablet">
  <MobileNavigation />
</Hide>
<Hide below="desktop">
  <DesktopNavigation />
</Hide>

Hide a component above or below a certain breakpoint

Request for comments

The exact API for each of these components is yet to be finalised. I'll request input for this, component-by-component at a later date.

I'd like to know whether this approach is something that would work for you and your team, and would solve most of your common layout issues? Also if you can think of any more components or abstractions that would be useful, please add them to this issue.

test issue

this is just a test for a team project

React warning on passing prop to DOM element

Describe the bug

In Storybook we're seeing the following error in dev on the icon-only link button story (<-- this link only works when running yarn storybook locally)

Warning: React does not recognize the `showIcon` prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase `showicon` instead. If you accidentally passed it from a parent component, remove it from the DOM element.
    in a (created by Context.Consumer)
    in EmotionCssPropInternal (created by LinkButton)
    in LinkButton
    in div (created by storyFn)
    in div (created by Context.Consumer)
    in EmotionCssPropInternal (created by storyFn)
    in div (created by storyFn)
    in storyFn
    in ErrorBoundary

This is because we are passing the (now unused) showIcon prop to the DOM in the LinkButton component. We could delete this prop entirely.

Expected behavior

We should not pass this prop to the underlying DOM element, so this warning would not appear