Displaying Content in Nuxt

Use this page when your schema exists and you want your Nuxt routes to render real Dyrected content instead of hardcoded placeholders.

By the end, you should know the recommended fetch path for a Nuxt page, how to render the common Dyrected field shapes, and what this page should cover directly before you branch into more advanced rendering patterns.

This page comes after schema and seed data are in place. Once one real route renders correctly, the next step is to open that same route in Dyrected's preview flow.

The mental model

In Nuxt, Dyrected does not render the page for you. Your route still owns the component tree. Dyrected's job is to supply the data shape, while your app decides how that data becomes markup.

That means displaying content is a two-part job:

1. fetch the right document
2. render each field with the right level of structure

Most fields are plain values. The special cases are usually:

• uploads and images
• rich text
• blocks

Recommended fetch path

For a Nuxt app, the simplest starting point is the module's SSR-aware composables:

• useDyrectedCollection when you need to query by fields like slug
• useDyrectedDoc when you already have a document ID
• useDyrectedGlobal for shared one-record globals

Those composables wrap the SDK client in useAsyncData, so they fit naturally into Nuxt's server rendering and caching flow.

A simple page route example

This example fetches one document from the pages collection and renders it in a route:

<script setup lang="ts">
const route = useRoute();

const { data: response } = await useDyrectedCollection("pages", {
  where: { slug: { equals: route.params.slug } },
  depth: 1,
  limit: 1,
});

const page = computed(() => response.value?.docs?.[0] ?? null);

if (!page.value) {
  throw createError({ statusCode: 404, statusMessage: "Page not found" });
}
</script>

<template>
  <article class="prose mx-auto">
    <h1>{{ page.title }}</h1>
    <DyrectedImage v-if="page.featuredImage" :media="page.featuredImage" :alt="page.title" />
    <DyrectedRichText v-if="page.content" :content="page.content" />
  </article>
</template>

The important pattern is not the styling. It is the separation:

• the route fetches typed content from Dyrected
• the page component decides how that content should look in the real site

Which renderer to use for common field shapes

The Nuxt integration auto-registers the helpers you will need most often:

• <DyrectedImage> for image uploads
• <DyrectedMedia> for mixed media
• <DyrectedRichText> for HTML produced by the editor
• <DyrectedBlocks> for block-based page sections

Use plain Vue markup for ordinary text, dates, booleans, and simple relationships. Reach for the helpers when the field shape already carries rendering semantics.

One Nuxt-specific detail is worth knowing early: <DyrectedImage> renders through <NuxtImg>, and the Nuxt module installs @nuxt/image for you during setup.

Rendering blocks

If your collection uses a blocks field, map each blockType to a real component:

<script setup lang="ts">
import { defineAsyncComponent } from "vue";

const blockComponents = {
  hero: defineAsyncComponent(() => import("~/components/blocks/HeroBlock.vue")),
  cta: defineAsyncComponent(() => import("~/components/blocks/CtaBlock.vue")),
};
</script>

<template>
  <DyrectedBlocks
    :items="page.layout"
    :components="blockComponents"
    path="layout"
  />
</template>

This matters for two reasons:

• it keeps the layout system in your codebase
• it gives live preview a stable way to map block content back to the right field paths later

Recommended path

For a first render path, do not try to make every collection dynamic at once.

Start by proving one page end to end:

1. fetch one collection
2. render one route
3. include one image or rich text field
4. confirm an edit in the admin changes the frontend output

Once that works, expand to shared navigation, more collections, and eventually block-based layouts if the site needs them.

Escape hatches

If JavaScript or TypeScript is not the consumer, drop down to the REST API Overview. For JavaScript and TypeScript inside Nuxt, the SDK and @dyrected/nuxt helpers should stay the default path.

For broader component coverage beyond the quick-start use case, continue to Displaying Content Overview and SDK API Overview.

Success check

You are ready for the next step when:

• a real Nuxt route renders content fetched from Dyrected
• the route handles missing documents safely
• at least one structured field shape is rendered with the proper helper instead of an ad hoc shortcut

Once that is true, continue to Adding a Visual Editor in Nuxt.