The @frontic/nuxt module provides seamless integration between your Nuxt application and Frontic backend. It includes composables for data fetching, automatic proxy configuration, and locale management.
Read contextDomain from the current @nuxtjs/i18n locale object. Requires @nuxtjs/i18n to be installed.
When not set, useFronticPage derives the domain from the request URL host (useRequestURL().host). This works in production where the host is the Frontic domain, but not when the host doesn’t match — for example in local development (localhost:3000), sandbox / preview environments, or staging where only the production domain is configured in Frontic.You can configure a domain alias in your Frontic dashboard as an alternative. If your dev environment uses a host that isn’t configured as an alias, set contextDomain to override it:
The module provides seamless configuration for Frontic UI — a set of ready-to-use, customizable components designed for Frontic storefronts. When enabled, the module auto-imports your Frontic UI components so they’re available everywhere in your app without manual imports, just like Nuxt’s built-in component auto-import.
Frontic UI is currently in open beta. We’d love to hear your feedback! If
you have questions or suggestions, please get in touch with
us.
Prefix for auto-imported Frontic UI components from your component directory. For example, setting 'Ui' would make Button.vue available as <UiButton />.
When a composable is disabled, it will not be auto-imported during the Nuxt build. This means you won’t get type errors or warnings - the composable simply won’t exist. Use this to reduce bundle size by excluding composables you don’t need.
The Frontic composables provide a smart data layer for your Nuxt application. Built on Pinia Colada, they handle caching, deduplication, and SSR hydration automatically - so you get instant UI updates with stale-while-revalidate, shared requests across components, and seamless server-to-client data transfer without any extra configuration.
useFronticBlock
Fetch single blocks (products, categories) with smart caching
useFronticListing
Fetch listings with automatic caching and SSR support
useFronticSearch
Full-featured search with filters, sorting, and smart state management
useFronticPage
Dynamic page routing with redirects and 404 handling
useFronticContext
Locale and region switching with cookie persistence
Fetch a listing by name and parameters with automatic caching and SSR support. Use this when you need to display items with simple interactive filtering or sorting. See Caching for details.
Building a page with interactive search, filters, sorting, or pagination? Use
useFronticSearch instead.
A ready-to-use backend for building stateful search and filter UIs. This composable handles all the interaction logic - filtering, sorting, pagination, and text search - with automatic caching and SSR support, so you can focus on crafting the perfect UI. See Caching for details.It follows best practices to reduce logic overhead in your templates, provides pre-processed filter and sort options with labels and counts, and seamlessly integrates with Frontic UI components.
Debounce delay in milliseconds for search input. Controls how long to wait
after the user stops typing before triggering a search request. Increase for
slower networks or to reduce API calls.
When true, filter methods (addFilter, removeFilter, etc.) are disabled and state.available.filter remains empty. Use this when your UI doesn’t need filtering controls.
A list of filter field names that should use OR logic, allowing users to select multiple values (e.g., “red OR blue”). Fields not listed use AND logic by default.
Controls how select is applied. With 'include', only the specified fields are shown. With 'exclude', all filters except the specified fields are shown.
Define the display order for filters. Keys listed here appear first in state.available.filter in the specified order. Any filters not in this array appear after in their original order.
When true, sorting methods (sortResult, resetSorting) are disabled and state.available.sorting remains empty. Use this when your UI doesn’t need sorting controls.
A list of sort options to control which sorts appear in state.available.sorting. Use the format 'field:order' (e.g., 'name:asc'). Use 'default' for the backend’s default sorting.
Controls how select is applied. With 'include', only the specified sort options are shown. With 'exclude', all sorts except the specified options are shown.
Human-readable labels for sort options. These appear in state.available.sorting for building sort dropdowns. Use 'default' key for the backend’s default sorting.
sorting: { label: { 'default': 'Relevance', 'name:asc': 'Name A-Z', 'name:desc': 'Name Z-A', 'price.amount:asc': 'Price: Low to High', 'price.amount:desc': 'Price: High to Low' }}
Define the display order for sort options. Keys listed here appear first in state.available.sorting in the specified order. Any sorts not in this array appear after in their original order.
Pre-processed search state ready for building your UI. Fully typed based on your listing’s filter and sort schema - with IDE autocomplete for filter keys, sort fields, and more. Contains everything needed to render filter sidebars, sort dropdowns, and pagination controls.
Two-way bindable search term. Connect this directly to your search input -
typing automatically triggers debounced API requests when the term exceeds
searchTermThreshold.
Reset all state (search term, filters, and sorting) to initial values and refresh results. Equivalent to calling resetSearch(), resetFilter(), and resetSorting() together. Use this for a “Clear All” button.
<button @click="reset">Clear All Filters & Search</button>
Add a single filter value while keeping existing selections. Use this for checkbox-style filters where users can select multiple options.
// User clicks "Red" checkboxawait addFilter('properties.color', 'red')// User also selects "Blue" - both are now activeawait addFilter('properties.color', 'blue')
Remove a specific filter value, or clear all values for a field if no value is provided. Use this when users uncheck options or click “clear” on a filter group.
// User unchecks "Red"await removeFilter('properties.color', 'red')// User clicks "Clear all colors"await removeFilter('properties.color')
Apply a sort order using the 'field:order' format. Call without arguments to reset to default sorting.
// Sort by name ascendingawait sortResult('name:asc')// Sort by price descendingawait sortResult('price.amount:desc')// Reset to default (backend's default order)await sortResult()
Navigate to the next or previous page, replacing the current results.
Returns true if navigation was successful, false if there’s no page in
that direction.
/** * Wrapper composable for product search. * * By using a fixed cacheKey, all components calling this composable * share the same search state automatically via Nuxt's useState. */export function useMySearch() { return useFronticSearch( "CategoryProducts", { key: "shoes" }, { // This cacheKey enables state sharing across components! cacheKey: "product-search", // Search configuration orFilter: ["properties.color", "properties.size"], filter: { select: ["properties.color", "properties.size", "properties.brand"], label: { "properties.color": "Color", "properties.size": "Size", "properties.brand": "Brand", }, }, sorting: { label: { default: "Relevance", "name:asc": "Name A-Z", "price.amount:asc": "Price: Low to High", }, }, }, );}
Why use a wrapper composable?
Centralized configuration - All your filter options, sort labels, and search settings live in one file. Need to add a new filter? Update it once.
Shared state - The cacheKey option enables automatic state sharing. When multiple components call the same wrapper, they share the reactive searchTerm, filter/sort state, result data, and pagination.
Clean components - Your page and filter components stay focused on rendering, not configuration.
Any action (like addFilter) called from one component automatically updates all other components using the same cacheKey.
Dynamic page routing with automatic slug detection, redirect handling, and 404 errors. Includes automatic caching and SSR support. See Caching for details.
The composable automatically constructs the page slug from the current request
URL (host + pathname). This works correctly in both SSR and client-side
navigation.
Disable automatic context fetching and cookie management. When true, you
must manually call refresh() to fetch contexts and manage the token
yourself. Overrides the module-level disableContext setting.
The module configures a path alias so you can import from your generated Frontic client:
import type { ProductCard, ProductFull } from "@frontic/stack/generated-types";import { createClient } from "@frontic/stack/generated-client";
This maps @frontic/stack/* to .frontic/* in your project root, where the
Frontic CLI generates your typed client.
All composables are fully typed with generics that preserve the specific block/listing types through to the return values, providing full IDE autocomplete for response data.