Skip to main content
The @frontic/nuxt module wires your Nuxt application to the Frontic backend. It ships composables for data fetching, automatic proxy configuration, and locale management.

Installation

This installs the module and adds it to your nuxt.config.ts automatically.
nuxt.config.ts
The module works out of the box with sensible defaults: CORS proxy enabled, all composables registered, and TypeScript paths configured.

Configuration

All options are optional. Customize behavior as needed:
nuxt.config.ts

Options

API

boolean | string
default:"true"
Enable the built-in CORS proxy at /api/frontic, or set a custom path.
string
API secret for protected environments. Server-only - never exposed to the browser.

Routing

boolean
default:"true"
Automatically redirect on 301 responses in useFronticPage.
boolean
default:"true"
Throw a 404 error when page is not found in useFronticPage.

Context

boolean
default:"false"
Disable automatic context fetching and cookie management in useFronticContext.
Cookie name for storing the context token.
Cookie max age in seconds. Default is 1 year.
string | boolean
Domain for page slug construction and API context resolution. Used by all composables.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 admin app as an alternative. If your dev environment uses a host that isn’t configured as an alias, set contextDomain to override it:

Frontic UI

The module configures 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, mirroring 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.
string
default:""
Prefix for auto-imported Frontic UI components from your component directory. For example, setting 'Ui' would make Button.vue available as <UiButton />.
string
default:"@/components/ui"
Directory path for Frontic UI components to auto-import.

Composables

boolean | FronticComposable[]
default:"true"
Control which composables are auto-imported during the Nuxt build.
When a composable is disabled, it will not be auto-imported during the Nuxt build. You won’t get type errors or warnings — the composable won’t exist. Use this to reduce bundle size by excluding composables you don’t need.

Composables

The Frontic composables provide a smart data layer for your Nuxt application. Built on Pinia Colada, they handle caching, deduplication, and SSR hydration automatically — instant UI updates via stale-while-revalidate, shared requests across components, and server-to-client data transfer without 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

useFronticTree

Hierarchical menu trees with automatic caching and SSR support

useFronticPage

Dynamic page routing with redirects and 404 handling

useFronticContext

Locale and region switching with cookie persistence

useFronticClient

Low-level client for direct API access

useFronticBlock

Fetch a single block (product, category, brand) by key with automatic caching and SSR support. See Caching for details.

Parameters

keyof Blocks
required
The name of the block to fetch. Provides full autocomplete for your generated block types.
string | Ref<string>
required
The key identifier for the block. Can be reactive for dynamic fetching.
object
Configuration options.

Returns

Ref<Responses[T] | undefined>
The block data, fully typed based on the block name.
Ref<'pending' | 'error' | 'success'>
Current query status for loading states.
() => Promise<void>
Refresh data using cache if still valid.
() => Promise<void>
Force a fresh fetch, bypassing cache entirely.

Example


useFronticListing

Fetch a listing by name and parameters with automatic caching and SSR support. Mirrors client.listing(name, params, { query }) — including the optional query for filter, sort, search, limit, and page. See Caching for details.
Building a page with interactive filter/sort/search controls or pagination bound to user input? Use useFronticSearch. useFronticListing is the right pick when the query is fixed at call time — homepage carousels with { limit: 10 }, server-rendered grids with a static filter, etc.

Parameters

keyof Listings
required
The name of the listing to fetch.
ListingParameters[T] | Ref
required
Parameters to pass to the listing endpoint. Type-safe based on listing name.
object
Configuration options.

Returns

Ref<Responses[T] | undefined>
The listing data with items and metadata.
Ref<'pending' | 'error' | 'success'>
Current query status.
() => Promise<void>
Refresh using cache if valid.
() => Promise<void>
Force fresh fetch.

Example


useFronticSearch

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.

Parameters

keyof Listings
required
The name of the listing to fetch.
ListingParameters[T] | Ref
required
Parameters to pass to the listing endpoint.
object
Configuration options.

Returns

State & Cache Control
Ref<Responses[T] | undefined>
The full listing response from the API, containing items, pagination metadata, and filter facets.
Ref<'pending' | 'error' | 'success'>
Current query status. Use this to show loading spinners or error states in your UI.
Ref<SearchState<TFilters, TSorts>>
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.
Ref<string>
Two-way bindable search term. Connect this directly to your search input - typing automatically triggers debounced API requests when the term exceeds searchTermThreshold.
() => Promise<void>
Re-fetch data, using cache if still valid within staleTime. Use this when you want to ensure fresh data but don’t need to bypass the cache.
() => Promise<void>
Force a fresh fetch, completely bypassing the cache. Use this when you know data has changed and need guaranteed fresh results.
() => Promise<void>
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.
Filter Actions
(field, value) => Promise<void>
Add a single filter value while keeping existing selections. Use this for checkbox-style filters where users can select multiple options.
(field, value?) => Promise<void>
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.
(field, values) => Promise<void>
Replace all values for a filter field at once. Use this for single-select filters or when setting multiple values programmatically.
(field?) => Promise<void>
Clear filters for a specific field, or all filters if no field is provided. Use this for “Reset” buttons.
Sort Actions
(sortBy?: string) => Promise<void>
Apply a sort order using the 'field:order' format. Call without arguments to reset to default sorting.
() => Promise<void>
Reset to the backend’s default sort order. Equivalent to calling sortResult() without arguments.
Pagination Actions
() => Promise<void>
Load the next page. In standard mode (the default), the current page is replaced with the next one. In infinite mode (infinite: true), items from the next page are appended to the existing list — use this for “Load More” buttons or infinite scroll.
() => Promise<void>
Load the previous page. In standard mode, the current page is replaced with the previous one. In infinite mode, items from the previous page are prepended to the existing list.
(page: number) => Promise<void>
Jump to a specific page number. In standard mode, the current page is replaced with the requested page. In infinite mode, all loaded pages are reset and the requested page becomes the new starting point.
Search Actions
Clear the search term and refresh results. Use this for a “clear search” button.

Example

Why use a wrapper composable?
  1. Centralized configuration - All your filter options, sort labels, and search settings live in one file. Need to add a new filter? Update it once.
  2. 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.
  3. 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.

useFronticTree

Fetch a Menu Tree — a hierarchical collection of records assembled from a Data Storage and rendered through a Detail Block — with automatic caching and SSR support. See Caching for details.

Parameters

keyof Trees
required
The name of the tree to fetch. Provides full autocomplete for your generated tree types.
object
Configuration options.

Returns

Ref<Responses[T] | undefined>
The full tree response ({ items?: [...] }), fully typed based on the tree name.
ComputedRef<TreeItems<Responses[T]> | undefined>
Shortcut for tree.value?.items. Fully typed based on the tree name — when your generated client is in place, items resolves to the concrete node array, so iterating gives you autocomplete on $items, key, and the block fields defined by the tree’s Detail Block (e.g. name, link).
Ref<'pending' | 'error' | 'success'>
Current query status for loading states.
() => Promise<void>
Refresh data using cache if still valid.
() => Promise<void>
Force a fresh fetch, bypassing cache entirely.

Example

The cache key includes key, depth, and contextKey, so different subtrees, depth caps, and contexts each cache independently — calling useFronticTree('CategoryNavigation') and useFronticTree('CategoryNavigation', { key: 'shop' }) from different components will not collide.

useFronticPage

Dynamic page routing with automatic slug detection, redirect handling, and 404 errors. Includes automatic caching and SSR support. See Caching for details.

Parameters

string | Ref<string>
The page slug. If omitted, auto-detected from current URL.
object
Configuration options.

Returns

Ref<Page | undefined>
The full page response object.
ComputedRef<Page['data'] | undefined>
The page data payload for rendering.
ComputedRef<string | undefined>
The page type for conditional rendering ('ProductCategory', 'ProductDetail', etc.).
ComputedRef<string | undefined>
The block name to render for this page.
ComputedRef<PageRoute | undefined>
Route information including redirect and context data.
ComputedRef<AlternateRoute[] | undefined>
Alternate language URLs for SEO hreflang tags.
ComputedRef<AlternateRoute | undefined>
Suggested route when context changes (e.g., for locale switching).
Ref<'pending' | 'error' | 'success'>
Current query status.
() => Promise<void>
Refresh using cache if valid.
() => Promise<void>
Force fresh fetch.

Example

pages/[...slug].vue
The composable automatically constructs the page slug from the current request URL (host + pathname). This works correctly in both SSR and client-side navigation.

useFronticContext

Manage locale and region switching with cookie persistence.

Parameters

object
Configuration options.

Returns

Readonly<Ref<ContextOption[]>>
Available context options with regions and locales.
Readonly<Ref<Context | null>>
Current active context.
Readonly<Ref<string | null>>
The current context token.
(context: { region: string; locale: string }) => Promise<void>
Switch to a different region/locale combination.
Readonly<Ref<boolean>>
Loading state during context operations.
() => Promise<void>
Manually refresh available contexts.

Example


useFronticClient

Low-level client for direct API access. All other composables use this internally.

Parameters

object
Configuration options for client behavior.

Returns

Returns a FronticClient instance with type-safe methods:
<T>(name, key, config?) => Promise<Responses[T]>
Fetch a block by name and key.
<T>(name, params, config?) => Promise<Responses[T]>
Fetch a listing with parameters and query options.
<T>(name, config?) => Promise<Responses[T]>
Fetch a menu tree by name. Pass key and/or depth under config.query to fetch a subtree or cap the depth.
(slug, config?) => Promise<Page>
Fetch a page by its slug.
(token, config?) => Promise<Context>
Get context by token.
(token?, config?) => Promise<[ContextOption[], string]>
Get available contexts.
(context, token, config?) => Promise<Context>
Update context with new region/locale.

Example


Proxy

The module includes a built-in proxy to prevent CORS issues on client-side requests.
1

Browser Request

Client sends request to your server at /api/frontic
2

Server Forwards

Your Nuxt server forwards the request to the Fetch API
3

Response Returns

Response flows back through your server to the browser
Server-side requests (SSR) go directly to the Fetch API without using the proxy.

TypeScript

The module configures a path alias so you can import from your generated Frontic 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.

Caching

All composables use Pinia Colada for intelligent caching:

Stale-While-Revalidate

Shows cached data immediately while fetching fresh data in the background

Automatic Deduplication

Multiple components requesting the same data share a single request

SSR Hydration

Data fetched on server transfers to client without duplicate requests

Configure Cache Duration

Manual Cache Control

All composables return two methods for cache control: