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:
- fetch the right document
- 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 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:
DyrectedImagefor image uploadsDyrectedMediafor mixed mediaDyrectedRichTextfor HTML produced by the editorBlocksfor 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
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:
- fetch one collection
- render one route
- include one image or rich text field
- 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.
Setting Up Initial Data
Use initialData to seed pages, globals, and safe defaults so a fresh Next.js environment can render real content immediately.
Adding a Visual Editor in Next.js
Add live preview and click-to-edit to a Next.js route that already renders Dyrected content, starting with the simplest supported preview flow.