DocsDocsSDKs

SearchProductCard

React SDK guidance for SearchProductCard.

Exact exports, props, slots, hooks, and runtime behavior belong to SDK package reference. Examples are guidance unless explicitly marked copy-paste-safe.

Review component intent and composition guidance before wiring this component into an app. Then use the live playground to confirm the rendered behavior.

Playground

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.

Provider requirement for slug and SKU lookups

The inline product source works in any tree that already renders Enad components. The slug and sku lookup paths need EnadProvider clientConfig=\{...\} so the connected wrapper can run the Search GraphQL lookup.

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.

Contract scope

  • Use SDK package reference for exact props, exports, slots, hooks, and runtime behavior.
  • Public import: @enadhq/enad-react-sdk/client/search.
  • Playground route: /sandbox?component=SearchProductCard.
  • Copy/paste scope: guidance-only. Treat examples as guidance until checked against SDK package reference.

Implementation notes

  • Search-backed components require provider, client, and search configuration before examples become live-data copy/paste snippets.

SearchProductCard

# SearchProductCard > Exact exports, props, slots, hooks, and runtime behavior belong to SDK package reference. Examples are guidance unless explicitly marked copy-paste-safe. Review component intent and composition guidance before wiring this component into an app. Then use the live playground to confirm the rendered behavior. ## Playground - Import path: `@enadhq/enad-react-sdk/client/search`. - Live playground: [/components/commerce/search-product-card](https://sdk.enad.io/components/commerce/search-product-card). ## 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. > **Provider requirement for slug and SKU lookups** > > The inline `product` source works in any tree that already renders Enad components. The `slug` and > `sku` lookup paths need `EnadProvider clientConfig={...}` so the connected wrapper can run the > Search GraphQL lookup. 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. ## Contract scope - Use SDK package reference for exact props, exports, slots, hooks, and runtime behavior. - Public import: `@enadhq/enad-react-sdk/client/search`. - Playground route: /sandbox?component=SearchProductCard. - Copy/paste scope: guidance-only. Treat examples as guidance until checked against SDK package reference. ### Implementation notes - Search-backed components require provider, client, and search configuration before examples become live-data copy/paste snippets.