mcpField
P
portable-text-serialization

portable-text-serialization

github.com/sanity-ioDevelopment1942.9k installsUpdated 1d ago
Repository

About portable-text-serialization

A reference skill for rendering Portable Text across frameworks with the `@portabletext/*` libraries. It explains component mappings, framework-specific rules, and patterns for custom content, missing components, and GROQ queries.

Key features

  1. 01Framework-specific Portable Text rendering
  2. 02Component mappings for blocks and marks
  3. 03Custom type rendering guidance
  4. 04Missing-component handling
  5. 05GROQ reference expansion guidance

Use cases

  1. 01Rendering Portable Text in a framework
  2. 02Mapping custom blocks and annotations
  3. 03Handling unknown content types
  4. 04Querying Portable Text with references

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sanity-io/agent-toolkit --skill portable-text-serialization

After installing, type/portable-text-serializationin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

rules/
astro.md
html.md
markdown.md
plain-text.md
react.md
svelte.md
vue.md

Details

From the project README

Portable Text Serialization

Render Portable Text content across frameworks using the @portabletext/* library family. Each library follows the same component-mapping pattern: you provide a components object that maps PT node types to framework-specific renderers.

Portable Text Structure (Quick Reference)

PT is an array of blocks. Each block has _type, optional style, children (spans), markDefs, listItem, and level.

Root array
├── block (_type: "block")
│   ├── style: "normal" | "h1" | "h2" | "blockquote" | ...
│   ├── children: [span, span, ...]
│   │   └── span: { _type: "span", text: "...", marks: ["strong", "<markDefKey>"] }
│   ├── markDefs: [{ _key, _type: "link", href: "..." }, ...]
│   ├── listItem: "bullet" | "number" (optional)
│   └── level: 1, 2, 3... (optional, for nested lists)
├── custom block (_type: "image" | "code" | any custom type)
└── ...more blocks

Marks come in two forms:

  • Decorators: string values in marks[] like "strong", "em", "underline", "code"
  • Annotations: keys in marks[] referencing entries in markDefs[] (e.g., links, internal references)

Component Mapping Pattern (All Frameworks)

Every @portabletext/* library accepts a components object with these keys:

KeyRendersProps/Data
typesCustom block/inline types (image, code, CTA)value (the block data)
marksDecorators + annotationschildren + value (mark data)
blockBlock styles (h1, normal, blockquote)children
listList wrappers (ul, ol)children
listItemList itemschildren
hardBreakLine breaks within a block—

Framework-Specific Rules

Read the rule file matching your framework:

  • React / Next.js: rules/react.md — @portabletext/react or next-sanity
  • Svelte / SvelteKit: rules/svelte.md — @portabletext/svelte
  • Vue / Nuxt: rules/vue.md — @portabletext/vue
  • Astro: rules/astro.md — astro-portabletext
  • HTML (server-side): rules/html.md — @portabletext/to-html
  • Markdown: rules/markdown.md — @portabletext/markdown
  • Plain text extraction: rules/plain-text.md — @portabletext/toolkit
Additional Community Serializers

These are listed on portabletext.org but don't have dedicated rule files:

TargetPackage
React Native@portabletext/react-native-portabletext
React PDF@portabletext/react-pdf-portabletext
Solidsolid-portabletext
Qwikportabletext-qwik
Shopify Liquidportable-text-to-liquid
PHPsanity-php (SanityBlockContent class)
Pythonportabletext-html
C# / .NETdotnet-portable-text
Dart / Flutterflutter_sanity_portable_text

Common Patterns (All Frameworks)

Custom Types Need Explicit Components

PT renderers only handle standard blocks by default. Custom types (image, code, callToAction, etc.) require explicit component mappings — they won't render otherwise.

Keep Components Object Stable

In React/Vue, define components outside the render function or memoize it. Recreating on every render causes unnecessary re-renders.

Handle Missing Components Gracefully

All libraries accept onMissingComponent to control behavior when encountering unknown types:

  • false — suppress warnings
  • Custom function — log or report
Querying PT with GROQ

Always expand references inside custom blocks:

body[]{
  ...,
  _type == "image" => {
    ...,
    asset->
  },
  markDefs[]{
    ...,
    _type == "internalLink" => {
      ...,
      "slug": @.reference->slug.current
    }
  }
}

Comments

Markdown supported