Architecture

Drop-ins at a glance

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

A drop-in uses three things: its npm package, initializer settings in the repository, and a mount point on the page. The storefront template already provides these for standard shopping features such as the product page, cart, mini cart, and checkout.

Start by understanding and customizing the existing implementation, not installing those drop-ins again. For a full package map, see Drop-ins introduction.

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

In this model, the project provides the npm package and initializer configuration. The mount point is an HTML element in the page’s DOM. The drop-in renders its UI there 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.

Where drop-ins run

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.

Use the included drop-ins first

The template declares its standard drop-ins in package.json. Its Commerce blocks and scripts/initializers/ already connect them to the configured endpoints and labels. Run your storefront locally covers installing the declared dependencies and preparing their browser assets.

Check the existing block and initializer before adding code. For a custom integration that the project does not already include, follow Connect a drop-in. To change an included feature, start with Extending drop-ins.

For our reference implementation, see the Commerce boilerplate repository .

How much can you customize?

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, B2B, and the package list

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 pages under Drop-ins B2B (company, quotes, purchase orders, requisition lists, and related topics).

These names show the pattern for consumer-facing drop-ins. Check the project’s package.json for its selected versions and the per-drop-in references for API and customization details. For business-to-business features, see 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