Build a storefront page
Compose storefront chrome, merchandising sections, and content blocks without moving app routing or data ownership into presentational components.
Use this guide when you are composing a marketing page, collection landing page, or editorial storefront route with the React SDK.
This guide describes flow and composition. Exact component props, child parts, and runtime behavior belong to SDK package reference.
Page ownership
A storefront page has three layers. The app shell owns routing, layout routes, analytics, CMS or data fetches, and auth state.
The SDK runtime sits inside EnadProvider. Use EnadProvider componentSet=\{...\} for an app-wide structural set, and add EnadThemeProvider only when a subtree needs scoped theme state. Page code then composes header or footer chrome, hero sections, galleries, cards, and link blocks.
Do not put app routing, analytics, CMS fetching, or commerce side effects into presentational component docs. Keep those concerns in the app shell or page loader.
Recommended build order
- Start from the first app guide so the stylesheet and provider boundary are correct.
- Add Header or HeaderSection for top chrome.
- Add the primary storefront section, such as Hero, Gallery, LinkBlock, or QuickLinks.
- Add product-display surfaces only after the page already owns product data.
- Add Footer as the closing shell.
- Validate the visual rhythm in the live playground or local app.
Composition sketch
Use this sketch to hold the page shape in your head while you choose exact imports and props from package reference.
import { EnadProvider } from "@enadhq/enad-react-sdk";
export function StorefrontRoute({ children }: { children: React.ReactNode }) {
return (
<EnadProvider componentSet="editorial">
{/* Header or HeaderSection */}
{/* Hero, content blocks, galleries, and product-display sections */}
{children}
{/* Footer */}
</EnadProvider>
);
}Import exact components and props from package reference when implementing the real page.
Product and media boundaries
Storefront sections can display merchandised product and media content, but they do not own the product model.
- ProductCard is a display primitive. Normalize product data before passing it in.
- ProductImage owns PDP media behavior, not generic card imagery.
- Gallery and image blocks display already-selected media. Asset selection, cropping, and CMS ownership remain outside the component.
- Header and Footer are chrome. The app still owns route targets, account state, cart count truth, and search integration.
When to use the playground
Use the live playground after you know the page structure.
- Compare component-set feel.
- Test hero and gallery visual rhythm.
- Check token changes.
- Validate whether a section-first component is enough before dropping to lower-level composition.
Do not copy playground-only inspection controls into the app. Keep the playground as a validation surface, not a source for app route internals.