Footer

React SDK guidance for Footer.

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 Footer when a storefront needs a shared closing shell but the app should still control the exact section order and structure.

It pairs naturally with HeaderSection or the lower-level Header family when the storefront wants the same shell-level control at both the top and bottom of the page.

That usually means:

  • support / help navigation columns
  • newsletter or editorial signup content
  • payment or trust content
  • a brand/legal closing row

Composition model

Footer is now entirely composition-first:

  • Footer.Main — high-level vertical stack wrapper
  • Footer.Columns — responsive columns grid
  • Footer.Column — one footer column
  • Footer.Heading — column heading
  • Footer.LinkList and Footer.Link — navigation primitives
  • Footer.Newsletter — newsletter/editorial region
  • Footer.Payments — trust/payment row
  • Footer.Divider — separator between upper and lower regions
  • Footer.Bottom — closing row container
  • Footer.Brand — brand/copyright cluster
  • Footer.Legal — legal / utility links cluster

The root provides the shell styling (bg-card text-card-foreground) and the standard responsive container width.

Use child slots for order, not more props

If a storefront wants newsletter above the columns, payment badges below the divider, or a larger brand region before the legal row, rearrange the child slots instead of expecting the root to expose more ordering props.

Behavior and theming guidance

The footer uses semantic card colors so it can separate cleanly from the page body while remaining themeable.

The default slot primitives intentionally stay lightweight:

  • Footer.Columns gives you the responsive grid
  • Footer.Link gives you consistent link styling
  • Footer.Bottom gives you a stacked-on-mobile, row-on-desktop closing region

Everything else is yours to compose.

Review notes

These notes define scoped usage boundaries without claiming exact prop or runtime truth beyond SDK package reference.

Footer stays scoped to the closing layout shell. The component organizes footer regions; the host app owns route targets, legal copy, newsletter submission, payment badge truth, and compliance requirements.

  • Use the composition parts to control region order instead of adding app-specific provider behavior to the footer root.
  • Keep newsletter, support, legal, trust, and payment content sourced from the app or CMS layer that owns those claims.
  • Do not hide critical purchase, delivery, or account-state behavior only in the footer; it should reinforce the experience, not become the sole operational control surface.

Contract scope

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

Implementation notes

Footer

# Footer > 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/storefront`. - Live playground: [/components/layout/footer](https://sdk.enad.io/components/layout/footer). ## When to use it Use `Footer` when a storefront needs a **shared closing shell** but the app should still control the exact section order and structure. It pairs naturally with `HeaderSection` or the lower-level `Header` family when the storefront wants the same shell-level control at both the top and bottom of the page. That usually means: - support / help navigation columns - newsletter or editorial signup content - payment or trust content - a brand/legal closing row ## Composition model `Footer` is now entirely composition-first: - **`Footer.Main`** — high-level vertical stack wrapper - **`Footer.Columns`** — responsive columns grid - **`Footer.Column`** — one footer column - **`Footer.Heading`** — column heading - **`Footer.LinkList`** and **`Footer.Link`** — navigation primitives - **`Footer.Newsletter`** — newsletter/editorial region - **`Footer.Payments`** — trust/payment row - **`Footer.Divider`** — separator between upper and lower regions - **`Footer.Bottom`** — closing row container - **`Footer.Brand`** — brand/copyright cluster - **`Footer.Legal`** — legal / utility links cluster The root provides the shell styling (`bg-card text-card-foreground`) and the standard responsive container width. > **Use child slots for order, not more props** > > If a storefront wants newsletter above the columns, payment badges below the divider, or a larger > brand region before the legal row, rearrange the child slots instead of expecting the root to > expose more ordering props. ## Behavior and theming guidance The footer uses semantic card colors so it can separate cleanly from the page body while remaining themeable. The default slot primitives intentionally stay lightweight: - `Footer.Columns` gives you the responsive grid - `Footer.Link` gives you consistent link styling - `Footer.Bottom` gives you a stacked-on-mobile, row-on-desktop closing region Everything else is yours to compose. ## Review notes These notes define scoped usage boundaries without claiming exact prop or runtime truth beyond SDK package reference. `Footer` stays scoped to the closing layout shell. The component organizes footer regions; the host app owns route targets, legal copy, newsletter submission, payment badge truth, and compliance requirements. - Use the composition parts to control region order instead of adding app-specific provider behavior to the footer root. - Keep newsletter, support, legal, trust, and payment content sourced from the app or CMS layer that owns those claims. - Do not hide critical purchase, delivery, or account-state behavior only in the footer; it should reinforce the experience, not become the sole operational control surface. ## Contract scope - Use SDK package reference for exact props, exports, slots, hooks, and runtime behavior. - Public import: `@enadhq/enad-react-sdk/client/storefront`. - Playground route: /sandbox?component=Footer. - Copy/paste scope: guidance-only. Treat examples as guidance until checked against SDK package reference. ### Implementation notes