Content Adapter Internals

How the AILK MDX content adapter resolves files, applies locale fallbacks, and returns typed ContentPage objects.

Showing Rendered view

Content Adapter Internals

The MDX content adapter is the bridge between content/ files and the JSON-LD pipeline. This article explains how it resolves pages, applies locale fallbacks, and surfaces typed data.

Resolution order

When a route calls getMdxSource(type, slug, locale), the adapter applies a three-level fallback chain:

  1. content/<locale>/<Type>/<slug>.mdx — locale-specific file
  2. content/<defaultLocale>/<Type>/<slug>.mdx — default locale fallback
  3. content/<Type>/<slug>.mdx — legacy non-prefixed layout (backward compat)

The first match wins. If none match, getPageSource returns null and the route calls notFound().

Frontmatter parsing

Frontmatter is parsed by gray-matter and validated against a Zod schema. Required fields: type, slug, title, description. Optional fields: publishedAt, updatedAt, image, schema.

listDetail

listDetail(type, locale) enumerates all MDX files under content/<locale>/<Type>/ and returns an array of { slug } objects. Routes use this for generateStaticParams.

Type safety

The adapter's ContentPage type is Zod-inferred — any mismatch between the frontmatter and the schema produces a build-time error, not a runtime exception.

Was this helpful?
Edit this page on GitHub