DocsDocsSDKs

SearchBar

React SDK guidance for SearchBar.

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 SearchBar when the page needs a straightforward search form with an input and submit button, without the overhead of autocomplete or suggestion management.

Composition notes

defaultValue sets the initial query and onSearch receives the final submitted value. The component manages the live field state internally, which keeps the API small for simple search flows.

Use defaultValue to seed the field from the current route or server-rendered search state before the component mounts. The submit button label is fixed to Search, so this component is best when the default storefront wording already fits the experience.

In search-backed storefronts, treat SearchBar as the query-entry surface and pair it with the provider-backed Search GraphQL layer from EnadProvider clientConfig=\{...\}. A common split is:

  • SearchBar owns query input and submission
  • route state or page state owns the active query string
  • useEnadGraphQLQueryContext() supplies marketSlug, storeGroupSlug, and locale
  • useSearchProductsQuery() and related helpers from @enadhq/enad-react-sdk/client/search own the React-connected Search GraphQL request flow
  • connected SearchProductCard, SearchProductRecommendations, and SearchProductVariantSelector live in that same client/search surface when the SDK should resolve product data for you
  • lower-level search-domain helpers, generated search GraphQL documents, and neutral search-model utilities also ship from @enadhq/enad-ts-sdk/search when a non-React layer needs the same contract

Behavior and theming guidance

Place the search bar where visitors already expect search to happen, such as the top of a search page or inside a compact utility area. If the experience later needs live suggestions, graduate to SearchAutocomplete instead.

Because the field is controlled internally after the first render, treat it as a lightweight submit form rather than a synchronized global search state container. If you need custom button copy, instant suggestions, or richer analytics hooks, step up to a more specialized search component instead of stretching this one.

If the page needs Search GraphQL data, keep that fetching concern outside the component. Submit the next query through onSearch, update page or route state, and let the surrounding screen resolve results through the GraphQL hooks exposed from @enadhq/enad-react-sdk/client/global.

Review notes

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

SearchBar stays submit-driven. The component captures a query and calls the supplied search handler; live data fetching, route updates, Search GraphQL hooks, and result rendering belong to the surrounding screen.

  • No live search provider is required for a plain submit-only form that hands the query to app code.
  • When the submitted query drives SDK Search GraphQL data, keep the root EnadProvider configured with shopper-facing clientConfig plus the required client/search configuration, then resolve results outside the bar.
  • Step up to SearchAutocomplete when the interaction requires suggestions, previews, keyboard suggestion selection, or debounced lookup.

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=SearchBar.
  • Copy/paste scope: guidance-only. Treat examples as guidance until checked against SDK package reference.

Implementation notes

  • SearchBar can stay submit-driven; only connect live data when the product surface needs suggestions or result previews.

SearchBar

# SearchBar > 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-bar](https://sdk.enad.io/components/commerce/search-bar). ## When to use it Use `SearchBar` when the page needs a straightforward search form with an input and submit button, without the overhead of autocomplete or suggestion management. ## Composition notes `defaultValue` sets the initial query and `onSearch` receives the final submitted value. The component manages the live field state internally, which keeps the API small for simple search flows. Use `defaultValue` to seed the field from the current route or server-rendered search state before the component mounts. The submit button label is fixed to `Search`, so this component is best when the default storefront wording already fits the experience. In search-backed storefronts, treat `SearchBar` as the query-entry surface and pair it with the provider-backed Search GraphQL layer from `EnadProvider clientConfig={...}`. A common split is: - `SearchBar` owns query input and submission - route state or page state owns the active query string - `useEnadGraphQLQueryContext()` supplies `marketSlug`, `storeGroupSlug`, and `locale` - `useSearchProductsQuery()` and related helpers from `@enadhq/enad-react-sdk/client/search` own the React-connected Search GraphQL request flow - connected `SearchProductCard`, `SearchProductRecommendations`, and `SearchProductVariantSelector` live in that same `client/search` surface when the SDK should resolve product data for you - lower-level search-domain helpers, generated search GraphQL documents, and neutral search-model utilities also ship from `@enadhq/enad-ts-sdk/search` when a non-React layer needs the same contract ## Behavior and theming guidance Place the search bar where visitors already expect search to happen, such as the top of a search page or inside a compact utility area. If the experience later needs live suggestions, graduate to `SearchAutocomplete` instead. Because the field is controlled internally after the first render, treat it as a lightweight submit form rather than a synchronized global search state container. If you need custom button copy, instant suggestions, or richer analytics hooks, step up to a more specialized search component instead of stretching this one. If the page needs Search GraphQL data, keep that fetching concern outside the component. Submit the next query through `onSearch`, update page or route state, and let the surrounding screen resolve results through the GraphQL hooks exposed from `@enadhq/enad-react-sdk/client/global`. ## Review notes These notes define scoped usage boundaries without claiming exact prop or runtime truth beyond SDK package reference. `SearchBar` stays submit-driven. The component captures a query and calls the supplied search handler; live data fetching, route updates, Search GraphQL hooks, and result rendering belong to the surrounding screen. - No live search provider is required for a plain submit-only form that hands the query to app code. - When the submitted query drives SDK Search GraphQL data, keep the root `EnadProvider` configured with shopper-facing `clientConfig` plus the required client/search configuration, then resolve results outside the bar. - Step up to `SearchAutocomplete` when the interaction requires suggestions, previews, keyboard suggestion selection, or debounced lookup. ## 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=SearchBar. - Copy/paste scope: guidance-only. Treat examples as guidance until checked against SDK package reference. ### Implementation notes - `SearchBar` can stay submit-driven; only connect live data when the product surface needs suggestions or result previews.