Blocks and the repository

This page shows where your Git repository sits between merchant-authored documents and shopper cart, checkout, or product flows. It also explains how content blocks differ from Commerce blocks and which boilerplate folders hold the wiring. blocks/ and scripts/initializers/ are not sample folders. They are the files you edit when a Commerce region on the page breaks or shows the wrong data.

How a page loads shows the timeline from document to API call.

This page focuses on ownership: authors work in documents, EDS converts tables into block divs, and your repository provides decorators, initializers, styles, and configurations so Commerce blocks load the correct drop-ins.

Comparing blocks and drop-in components

Each document table becomes a block div that EDS and your JavaScript identify. Your repo connects Commerce blocks to drop-ins through decorators, scripts/initializers/, styles, and storefront configuration, then pushes to GitHub to drive Edge Delivery builds.

Authoring references: Document Authoring documentation , Document Authoring and Universal Editor Quick Starts, authoring guide , AEM documentation . For packages and shared vocabulary, see Drop-ins at a glance and Boilerplate getting started.

	Content blocks	Commerce blocks	Drop-in components
Role	Layout and marketing UI (cards, heroes, columns, headers, footers)	Interactive Commerce experiences (cart, checkout, account, PDP, …)	Packaged UI and logic that Commerce blocks load and initialize
Where it comes from	Block Collection and custom blocks in blocks/	Commerce blocks in blocks/, mapped in the boilerplate	npmNode's package manager. You use it to install drop-in packages — for example, `npm install @dropins/storefront-cart` — in your storefront repository. packages such as @dropins/storefront-cart
Authored as document tables	Yes	Yes	No — developers add packages and wire initializers in code
Typical tie to Adobe Commerce	None — no Commerce GraphQL for most blocks	Yes — GraphQL, REST, and services through the boilerplate	Direct — Commerce API calls (GraphQL, REST, services) are built into each package
Learn more	Block Collection	Key files and folders · Blocks reference	Drop-ins introduction

Commerce Storefront SDK

Drop-in components are built on shared Commerce Storefront SDKThe Drop-in SDK used to build custom drop-ins and related integration logic. patterns (initialization, rendering, slots, and extension hooks) so behavior and structure stay consistent across cart, checkout, product discovery, and the rest of the set.

• Commerce Storefront SDK — Reference for APIs, design components, and utilities used across drop-in components
• Drop-ins introduction — Full map of B2C and B2B drop-in components and how they install into the boilerplate

Content blocks and Commerce blocks

Both kinds are document tables EDS turns into HTML. The split is what runs next. Content blocks are layout and marketing (cards, columns, headers, footers from the Block Collection ). They contain no drop-ins or Commerce GraphQL. Commerce blocks load interactive cart, checkout, account, PDP, and similar flows via initializers and @dropins/* calling Commerce GraphQL and related APIs. Prefer plain JavaScript for Commerce blocks. React can make achieving a top Lighthouse score hard. See Libraries and the boilerplate blocks as patterns.

Key files and folders

The Adobe Commerce boilerplate is your project’s Git repository. It separates core AEM block delivery from Commerce-specific code (scripts/commerce.js, scripts/initializers/, and storefront configuration) so both sides stay maintainable independently.

Here is what the top-level layout looks like when you clone the boilerplate.

aem-boilerplate-commerce/
├── blocks/
│   ├── commerce-cart/
│   │   ├── commerce-cart.js      # block decorator — loads and mounts the Cart drop-in
│   │   └── commerce-cart.css
│   └── commerce-checkout/
│       ├── commerce-checkout.js  # block decorator — loads and mounts the Checkout drop-in
│       └── commerce-checkout.css
├── scripts/
│   ├── scripts.js                # page orchestration (eager, lazy, delayed phases)
│   ├── commerce.js               # Commerce-specific loading and configuration
│   └── initializers/
│       ├── cart.js               # sets the GraphQL endpoint and labels for the Cart drop-in
│       └── checkout.js           # sets the GraphQL endpoint and labels for the Checkout drop-in
├── styles/
└── config.json                   # storefront configuration (endpoints, locale, and so on)

The table below explains each key file or folder in detail. For the full Scripts folder in the boilerplate and blocks/:

File/Folder	Role
scripts/scripts.js	Page load, block decoration, fonts, and orchestration of eager, lazy, and delayed loading phases. Imports from scripts/aem.js and scripts/commerce.js. Also the extension point for global DOM decorators, third-party plugins (such as experimentation tools), and any code that must run eagerly on page load.
scripts/commerce.js	Commerce-specific loading, templates, page type detection, Adobe Client Data Layer (ACDL) initialization, and storefront configuration. ACDL is a JavaScript library that captures shopper behavior for analytics — you will see it again when you read about drop-in coordination and analytics. Centralizes all commerce features and keeps them distinct from core AEM logic.
scripts/initializers/	One file per drop-in. Each initializerA JavaScript module that configures a drop-in when imported, such as setting endpoints, registering dictionaries, and preparing runtime behavior. sets the GraphQL endpoint, loads UI string translations, and registers the drop-in for rendering. All of that runs at import time, before any block decorates. See Using drop-ins for the code pattern.
blocks/	Commerce and content blocks. See Content blocks and Commerce blocks above and Getting started for the repo layout.

Customize and connect: Blocks reference, Blocks configuration, Storefront configuration.

What’s next

Drop-ins at a glance explains packages, browser runtime, and npm install.