Hooks

Frontend-core and orchestr expose Nuxt runtime hooks that let you extend or modify the complete behaviour of your Laioutr Frontend. Register hooks inside a Nuxt plugin for client-side hooks, or a Nitro plugin for server-side hooks.

Hook mechanics

Every hook uses one of four mechanics, which decide when your handler runs and how it shapes the result:

• Filter — runs after the default logic with result.value pre-seeded. Transform it, replace it, or leave it untouched. Chained across plugins: each handler receives the previous one's output.
• Override — runs before the default with result.value empty. Set it to take over; leave it unset to fall back to the default.
• Modify — mutates the payload object in place. There is no result slot.
• Lifecycle — a before / success / error / finally sequence around an operation.

Each hook also has a dispatch, shown on its card. Synchronous handlers run inline and are not awaited — set values immediately, since a returned promise is ignored. Asynchronous handlers may await. Dispatch is a property of the individual hook, not of its mechanic.

Frontend Core Hooks

These hooks run on the client. Register them in a Nuxt plugin with nuxtApp.hook().

Link Resolver

Three hooks let you customize how linkResolver resolves links, switches locale paths, and switches market URLs.

Page Renderer

Page Head

Content Preview

Two hooks around content preview: one decides where the preview token comes from, the other tells you when preview turned on or off.

Analytics

Three hooks along the emission pipeline. Every event passes through them in order: :emit can veto it, :enrich shapes the whole event, and :project shapes each orchestr entity found in the payload.

Redaction is global, not per destination

The bus hands the same event object to every eligible destination. There is no seam between enrichment and an individual destination, so an app cannot give one destination a redacted payload and another the full one — whatever you change in :enrich or :project, every destination sees.

A destination author can of course shape their own output inside track(), since that code owns what it sends. What you cannot do from outside is redact someone else's destination. If two destinations need genuinely different data, that difference has to live in the destinations themselves.

Orchestr Client Hooks

These hooks fire during client-side action execution. All receive a token string that identifies the action (e.g. ecommerce/cart/add-items).

Fetch Action Hooks

Mutation Action Hooks

The context value comes from Pinia Colada's mutation context and is set by the onMutate callback.

export default defineNuxtPlugin((nuxtApp) => {
  // Track all failed actions (both fetch and mutation)
  nuxtApp.hook('orchestr:action:fetch:error', ({ token, error }) => {
    errorTracker.capture(error, { action: token, type: 'fetch' });
  });

  nuxtApp.hook('orchestr:action:mutation:error', ({ token, error }) => {
    errorTracker.capture(error, { action: token, type: 'mutation' });
  });
});

URL Query Parameters

Two hooks control how Orchestr reads and writes URL query parameters (pagination, sorting, filters). See URL Query Parameters for the full reference with examples.

Client Environment

Orchestr Server Hooks

These hooks fire during server-side action handler execution. They are Nitro runtime hooks and must be registered in a Nitro plugin, not a Nuxt plugin.

export default defineNitroPlugin((nitroApp) => {
  const pending = new Map<string, number>();

  nitroApp.hooks.hook('orchestr:action:handler:before', ({ token }) => {
    pending.set(token, Date.now());
  });

  nitroApp.hooks.hook('orchestr:action:handler:error', ({ token, error }) => {
    const startedAt = pending.get(token);
    const duration = startedAt ? Date.now() - startedAt : undefined;
    console.error(`[orchestr] ${token} failed after ${duration}ms`, error);
    pending.delete(token);
  });
});