Button

Overview

Import

Import the component from @faststore/ui

import { Button } from '@faststore/ui'

Import Styles

import '@faststore/ui/src/components/atoms/Button/styles.scss'

Usage

<Button variant="primary">Add to Cart</Button>

Props

Design Tokens

Nested Elements

Icon

<Button variant="primary" icon={<Icon name="ShoppingCart" />} iconPosition="left">
  Add to Cart
</Button>

Hierarchy

Primary

<Button variant="primary">Button</Button>

Primary Inverse

<Button inverse variant="primary">
  Button
</Button>

Secondary

<Button variant="secondary">Button</Button>

Secondary Inverse

<Button inverse variant="secondary">
  Button
</Button>

Tertiary

<Button variant="tertiary">Button</Button>

Tertiary Inverse

<Button inverse variant="tertiary">
  Button
</Button>

Variants

Disabled

<Button variant="primary" disabled>
  Button
</Button>

Loading

Small

<Button variant="primary" size="small">
  Button
</Button>
<Button variant="primary" size="small" icon={<Icon name="ShoppingCart" />}>
  Button
</Button>

Use Cases

Use the Button component to communicate user actions on the following components:

• Buy-now and add-to-cart buttons on Product Cards
• Call-to-action buttons on Cards
• Submit and/or withdraw actions on Forms
• Submit and/or withdraw actions on Modal windows.

Customization

For further customization, you can use the following data attributes:

data-fs-button

data-fs-button-variant="primary | secondary | tertiary"

data-fs-button-inverse

data-fs-button-size="small | regular"

data-fs-button-loading="true"

Best Practices

✅ Do's

• Use standard button designs and shapes to make your button look clickable.
• Use styles to communicate the importance of an action by visually differentiating Primary and Secondary buttons.
• Make buttons finger-friendly for mobile users and large enough for reliable interactions. Generally, touch targets are at least 44 by 44 CSS pixels.
• Use task-specific words to write button labels.
• Place the buttons in an order that reflects a conversation between the user and the system.
• Provide visual or audio feedback on interactions. Whenever a user interacts with a button, the button should change its state and let the user know that something is happening as a consequence.
• Define a style system for your button states (i.e., normal, focus, hover, active, pressed, disabled).
• Use icon-only buttons only for widespread actions with highly standardized icons, such as a cross for close.
• Use the aria-label attribute to provide a textual alternative for icon-only buttons.

❌ Don'ts

• Don’t make users hunt for buttons. Place buttons where users expect to see them or can easily find them.
• Don't rely on icons to communicate complex actions.
• Don't use generic words that can potentially confuse users.
• Avoid cluttering the UI with too many buttons.
• Avoid having more than one Primary action button on the screen at a time.
• Avoid using disabled buttons, if possible. Instead, give preference to hiding the unavailable option.
• Don't place buttons next to Badges. Although badges and buttons are similar in appearance, badges are not interactive and may confuse users if not used in the proper context.
• Don't use Buttons as Links. Links are not intended to invite users to take action. Instead, they redirect users somewhere.
• Avoid using aria-label when the button already has a label.

Related components