Skip to content

Search is only available in production builds. Try building and previewing the site to test it out locally.

Storefront Architecture

Drop-ins at a glance

A drop-in is a packaged piece of UI and logic for one Commerce job, such as cart, checkout, or sign-in. It loads Commerce data through APIs, often GraphQL.

To use a drop-in, you need three things: the npm package, initializer settings in your repo, and a mount point on the page.

For setup steps, see Using drop-ins.
For a full package map, see Drop-ins introduction.

One drop-in: what you provide and what it does

Section titled “One drop-in: what you provide and what it does”

In this model, your project provides the npm package, initializer configuration, and DOM mount point. The drop-in then renders the UI and calls Commerce APIs from the browser. For the full path from document to mount, see How a page loads.

Loading diagram...
Your project provides three things: the npm package, the initializer settings (GraphQL endpoint and language labels), and a mount point in the DOM. The drop-in component uses all three to render the shopper-facing UI and send Commerce API calls from the browser.

After load, drop-ins run in the browser. EDS delivers HTML, CSS, and JS. Commerce requests go straight from the drop-in to your endpoints, not through EDS in the middle.

Install the drop-in via npmNode's package manager. You use it to install drop-in packages — for example, `npm install @dropins/storefront-cart` — in your storefront repository. (for example, @dropins/storefront-cart). Packages are published on npm, with source code in private repositories.

Commerce blocks and scripts/initializers/ load each drop-in using your configured endpoint and labels.

For setup steps, see Using drop-ins.
For a reference implementation, see the Commerce boilerplate repository .
To go deeper, see Extending drop-ins.

More than you might expect. Each drop-in exposes several customization layers so you can change behavior without editing the package source.

  • CSS variables and stylesheet overrides control colors, spacing, typography, and layout.
  • Label overrides change UI text (button labels, errors, placeholders) without opening the package code.
  • Slots add custom content (for example, a banner or promo message) in named regions of the drop-in layout.
  • Extension hooks replace logic for specific actions, such as what runs when a shopper clicks Add to cart.

Most projects stop at CSS and labels. Slots and hooks are there when configuration alone is not enough. See Extending drop-ins for patterns and examples.

B2C means business-to-consumer (a typical shopper storefront). B2B means business-to-business (accounts, quotes, purchase orders, and similar flows).

The Drop-ins introduction lists B2C and shared packages. If you build B2B experiences, you will use extra packages and guides under Drop-ins B2B (company, quotes, purchase orders, requisition lists, and related topics).

These names show the pattern for consumer-facing drop-ins. Treat the per-drop-in install pages as the source of truth if a name or version changes. B2B installs are covered in Drop-ins B2B.

  • @dropins/storefront-account
  • @dropins/storefront-auth
  • @dropins/storefront-cart
  • @dropins/storefront-checkout
  • @dropins/storefront-order
  • @dropins/storefront-payment-services
  • @dropins/storefront-pdp
  • @dropins/storefront-recommendations
  • @dropins/storefront-wishlist
  • @dropins/storefront-personalization
  • @dropins/storefront-product-discovery

How drop-ins coordinate on a page explains how multiple drop-ins work together using a shared event bus.