When to use it

Use SearchProductCard when the page wants the SDK to resolve or accept search-backed product data and then render it through the standard ProductCard composition.

It is the fast path for:

• connected search results that still look like normal product cards
• editorial or merchandising slots that identify products by slug or SKU
• apps that already have a search product record and want ENAD to map it into the card contract

If the page already owns normalized card props or a non-search product model, stay on ProductCard instead.

Composition notes

SearchProductCard keeps the boundary sharp:

• ProductCard stays presentational
• SearchProductCard owns the search-backed lookup and mapping step

source supports three adoption paths:

• { type: "product", product } when the page already has a search product record
• { type: "slug", slug } when the SDK should resolve the product by slug
• { type: "sku", sku } when the SDK should resolve the product by SKU

productCard lets you tune the final presentational card props without breaking that boundary, and resolveProductHref is the right place to attach storefront navigation.

If the shell needs custom loading, error, or empty states around the card, drop to useSearchProductCard() and render ProductCard yourself.

Behavior and theming guidance

Because the wrapper renders the same ProductCard underneath, layout choice, image treatment, and merchandising tone should follow the same rules as the presentational card family.

Use the connected wrapper when data lookup is the variable. Use the presentational card when layout is the variable.