Components

A Fontdue component is a self-contained piece of UI you embed on your site – the Store Modal for cart and checkout, Type Testers for previewing fonts at custom sizes, the Character Viewer for browsing glyphs, and so on. Each one ships in two forms from the same underlying source: an HTML custom element you use with the script tag (e.g. <fontdue-buy-button>), and a React component you import from the fontdue-js npm package (e.g. <BuyButton>).

The pages in this section are the reference for every component, covering both integration paths.

Tuning component behavior

Most components ship with sensible defaults, but you’ll usually want to tune a few – the type tester’s size range, whether controls stay hidden until hover, the label on a Select button. All of this comes through the config object you pass to fontdue.initialize() on the script tag, or to <FontdueProvider config={...}> in React:

<script type="module">
  import fontdue from "https://js.fontdue.com/fontdue.esm.js";

  fontdue.initialize({
    url: "https://your-site.fontdue.com",
    config: {
      typeTester: {
        size: { min: 6, max: 480 },
        selectable: true,
        shy: true,
        buyButton: true,
      },
    },
  });
</script>

The example above configures the type tester: font sizes from 6 to 480 pixels, a style-picker dropdown, controls that stay hidden until hover, and a Buy button next to each tester. See Configuration for the full field list across type testers, the Store Modal, forms, and Stripe.

On the npm package path the same config object goes on the provider that wraps your app, and defaults set there apply to every component below it:

<FontdueProvider config={{ typeTester: { size: { min: 6, max: 480 }, selectable: true } }}>

A prop on an individual component overrides the provider default wherever you need it.¹¹Island-based frameworks like Astro render each component as its own root rather than inside a shared provider tree, so there’s no global config to inherit – pass the config object to each island directly. On Next.js’s server-rendered path the reverse holds: set config on the provider, since a per-component config prop isn’t read there. See Add the provider.

Lazy and preloaded

On the React path, every component that shows catalog data comes in two forms. A lazy component fetches its own data in the browser from an identifier you pass it – a collectionSlug, a collectionId, or a family and style name. A preloaded component renders from data you fetched on the server ahead of it: you call the component’s load{Component}Query helper in your loader and hand the result to its preloadedQuery prop. Which form you reach for is settled by your framework – lazy versus preloaded pins that down – and the two are mutually exclusive: pass an identifier or a preloadedQuery, never both.

Six components ship a preload helper: the Buy Button, Character Viewer, Type Testers, Type Tester, Newsletter Signup, and Test Fonts Form. The other three – the Store Modal, Cart Button, and Customer Login Form – are always lazy: they render from per-visitor state like the cart or a login session, which there’s nothing to preload on the server. Each page below shows the forms its component supports.

Customizing markup with HTML attributes

When the standard buttons don’t fit – you want your own markup, custom styling, or to pre-select a SKU – add fontdue-* attributes to any HTML element. Covered per-component on Buy Button and Cart Button. Script-tag integration only.

The components

Each page documents what the component renders, its props and attributes, and shows working examples in both integration paths.

Beyond the components, fontdue-js also exports a few React hooks – for loading webfonts, reacting to consent, and fitting text to its container – for the cases these components don’t cover.