Dyrected
GuidesNext.js

Displaying Content in Next.js

Fetch Dyrected content in Next.js, render common field types correctly, and prove one real route before moving into preview.

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

By the end, you should know the recommended fetch path for a Next.js 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 Next.js, 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

For a Next.js app, the simplest starting point is the framework package's server-side client helper:

import { getDyrectedClient } from "@dyrected/next/server";

const client = getDyrectedClient();

That helper creates a Dyrected SDK client from the current environment variables, so your route can fetch data without rebuilding the client setup on every page.

A simple page route example

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

import { notFound } from "next/navigation";
import { getDyrectedClient } from "@dyrected/next/server";
import { DyrectedImage, DyrectedRichText } from "@dyrected/next";

export default async function CmsPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const client = getDyrectedClient();

  const { docs } = await client.collection("pages").find({
    where: { slug: { equals: slug } },
    depth: 1,
    limit: 1,
  });

  const page = docs[0];

  if (!page) notFound();

  return (
    <article className="prose mx-auto">
      <h1>{page.title}</h1>
      {page.featuredImage ? <DyrectedImage media={page.featuredImage} alt={page.title} /> : null}
      {page.content ? <DyrectedRichText content={page.content} /> : null}
    </article>
  );
}

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 Next.js integration re-exports the helpers you will need most often:

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

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

Rendering blocks

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

import { Blocks } from "@dyrected/next";
import { HeroBlock } from "@/components/blocks/HeroBlock";
import { CtaBlock } from "@/components/blocks/CtaBlock";

<Blocks
  items={page.layout}
  path="layout"
  components={{
    hero: HeroBlock,
    cta: CtaBlock,
  }}
/>;

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

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 Next.js, the SDK and @dyrected/next 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 Next.js 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 Next.js.

On this page

Dyrected| Cloud

Get your backend ready in minutes

Use a managed database, storage, APIs, and admin dashboard without setting up the infrastructure yourself.

Set Up My Backend