Dramatic Improvement in Next.js Blog Expressiveness: microCMS API Design Separating "Text" and "Functionality"

Dramatic Improvement in Next.js Blog Expressiveness: microCMS API Design Separating "Text" and "Functionality" のビジュアル

When operating a blog with microCMS, it's difficult to place advertisement tags or implement complex layouts (such as product cards or CTAs) using only the standard "rich editor".
This article reveals the schema design for "block editor conversion," where the article body field is completely migrated from a single editor to a "repeat field (body_blocks)," and articles are constructed by combining 11 types of custom components.

  • 設計思想記事本文を巨大なHTML文字列ではなく、意味のある「ブロックデータの配列」として管理する。
  • 収益化affiliate_html(生HTML)やproduct_card(構造化データ)を専用フィールド化し、ASPタグや物販リンクを安全に管理。
  • 拡張性cta_buttonやinfoBoxなど、デザイン済みのパーツをAPI側で定義することで、フロントエンドの実装負荷を下げつつデザインを統一。
  • 実装Next.js側ではbody_blocks配列をループし、fieldIdに応じたReactコンポーネントを動的にレンダリングするだけで完了する。

Introduction: A single rich editor becomes a bottleneck in 'operations'

When creating a blog with a headless CMS like microCMS, one often starts with just a 'title' and 'body (rich editor)'. However, you quickly encounter problems as you continue operating it.

  • 'Moshimo Affiliate easy links (script tags) are deleted by the editor'
  • 'I want to create a nice product card with Amazon and Rakuten links side-by-side, but writing raw HTML is painful'
  • 'I want to enable syntax highlighting for code blocks'

The solution I arrived at to solve these problems was to turn the article body into a 'Repeated Field'.

This time, I will reveal the full scope of the `body_blocks` repeated field, which is actually in use on my blog, and its core schema design.

Solution: Make the entire article `body_blocks` (a repeated field)

On my blog, the main body of an article is defined by a single repeated field called `body_blocks`. Authors create articles by stacking the necessary parts (blocks) from top to bottom, much like a block editor in Notion or WordPress Gutenberg.

Core Schema Design: Definition of all 11 Block Types

Here is a breakdown of the custom fields actually defined in microCMS. Roles are clearly separated by purpose.

1. Base 'Text' and 'Advertisement'

This section forms the basic structure of the article.

rich_text (Text Block)

A rich editor for writing regular text.

  • Field: text_fields (Rich Editor)
  • Role: Responsible for basic writing such as headings (H2, H3), regular paragraphs, and bold text.

affiliate_html (Ad Block)

This is a crucial point for monetization. It avoids rich editor sanitization.

  • Field: notes (Text Area)
  • Role: Paste HTML code for banners and script tags from Moshimo Affiliate and A8.net directly. Using a text area prevents processing by the CMS, allowing it to be output as-is on the Next.js side.

Instead of simply pasting links, managing them as structured data allows the frontend to convert them into rich UIs (e.g., card-style).

product_card (Product Card)

Manages 'Moshimo Easy Links' and proprietary product sales links.

  • Field:
    • notes (Moshimo Easy Link Code)
    • title (Amazon Link, Rakuten Link, Yahoo Link) * Each URL
    • title (Product Name)
    • insert_photo (Product Image URL)
  • Benefit: By holding 'URLs' and 'product names' as data instead of saving HTML, the appearance of all past articles can be changed at once when the design is updated.

cta_button (CTA Button)

Buttons placed at the end of an article, such as 'Contact Us' or 'Go to Official Site'.

  • Field:
    • title (Button Label)
    • title (Link URL)
    • list (Button Style Selection: Primary / Secondary / Outline etc.)
    • toggle_on (External URL Check: if true, target="_blank")
    • toggle_on (Affiliate Check: if true, rel="sponsored")
    • title (Supplemental Text: "* Registration takes 3 minutes" etc.)

3. 'Functional' Elements Essential for Tech Blogs

codeBlock (Code Block)

Indispensable for engineer blogs.

  • Field:
    • notes (Code Body)
    • title (Language: js, css, python etc.)
    • title (File Name/Title)

For link cards that fetch and display OGP, like those on Zenn or Qiita.

  • Field: title (URL), notes (Memo)

4. 'Decorative' Elements for Rich Articles

  • quotePanel (Quote): Manages quote content and source information separately. Also supports quoting lines from manga, etc.
  • infoBox (Notice): Select 'Warning', 'Info', 'Success', etc. from a select box to display alerts.
  • figureImage (Single Image): Manages images, captions, and alt text as a set.
  • videoEmbed (Video): Enter URLs for YouTube, etc.
  • dataTable (Table): Used when a table with more advanced features than the rich editor's table function is required.

Implementation Image on the Next.js Side

On the frontend, you simply iterate through the receivedbody_blocks array with a map function and render different components based on the fieldId.

Three Benefits of This Design

1. Ad Tags (scripts) Run Safely

By defining affiliate_html as a 'text area' and processing it appropriately on the Next.js side (e.g., with dangerouslySetInnerHTML), you can use ASP tags as they are, without interference from microCMS editor specifications.

2. Resilient to Design Changes (Separation of Data and Presentation)

For example, if you want to 'change the button design', direct HTML writing would require modifying all articles. However, with this design, just changing one line of CSS in the CtaButton component will instantly reflect the change across all past articles.

3. Improved Writing Experience

Since you just select a block like 'Next is code' or 'Next is product introduction' and fill out the form, there's no need to worry about HTML tags. Authors can focus solely on the content.

Summary: Design is Key for Headless CMS

This component-oriented design, utilizing 'repeated fields', may require initial setup effort, but it dramatically reduces long-term operational costs.

In particular, holding conversion-related elements like 'product cards' and 'CTAs' as structured data will significantly enhance the future asset value of your blog.

If you are currently struggling with the limitations of rich editors, please consider migrating to body_blocks.

Revised New Edition: Design Principles Learned from Good Code/Bad Code - How to Write Maintainable, Continuously Evolving Code [ Daiya Senba ]

Revised New Edition: Design Principles Learned from Good Code/Bad Code - How to Write Maintainable, Continuously Evolving Code [ Daiya Senba ]

Was this article helpful?