microCMSでのカスタムフィールドの定義で気をつけていること
背景
現在、仕事で microCMS × Nuxt3 の構成で開発を行っています。microCMS側でカスタムフィールドを定義し、ページコンテンツを柔軟に組み立てるようにしています。
そんな中、ふとあることに気づきました。
あれ?似たようなカスタムフィールド、めっちゃ増えてない?
ページコンポーネントごとにそれぞれ別のカスタムフィールドを定義しているけれど、よく見てみると構造やスタイル指定のプロパティがかなり重複していました。
実例:アコーディオンとタブ
たとえば、アコーディオンのフィールドを定義すると、こんな感じになります。
interface AccordionItem {
fieldId: "accordionItem";
title: string;
content: string;
}
interface AccordionBlock {
fieldId: "accordionBlock";
textColor: string; // 共通の文字色
backgroundColor: string; // 共通の背景色
subColor: string; // 共通のサブカラー
items: AccordionItem[];
}
一方、タブコンポーネントも似たような構造です。
interface TabItem {
label: string;
content: string;
}
interface TabsBlock {
activeColor?: string;
backgroundColor?: string;
items: TabItem[];
}
見えてきた課題
-
構造の重複
-
items
という配列に何かしらの「ラベル+コンテンツ」を持つ構造が多い。 - 共通で
textColor
やbackgroundColor
を持っている。
-
-
スタイル設定の重複
- コンポーネントごとに色、余白、フォントサイズなどの指定フィールドが増えてくる。
- 最初は柔軟でいいけど、だんだん煩雑になってくる。
解決のアプローチ
✅ 1. 共通の型を分離する
たとえば、スタイル設定は共通型に分けておくことで、DRYに保てます。
interface CommonStyle {
textColor?: string;
backgroundColor?: string;
subColor?: string;
}
interface AccordionBlock extends CommonStyle {
fieldId: "accordionBlock";
items: AccordionItem[];
}
interface TabsBlock extends CommonStyle {
fieldId: "tabsBlock";
items: TabItem[];
}
CommonStyle
を使うことで、見た目に関する設定を再利用しやすくなり、命名・設計のブレも防げます。
✅ 2. UIパターンごとの共通インターフェース化
label + content
の組み合わせって、FAQ・アコーディオン・タブなどでよく使いますよね。こういったパターンも、共通の構造として抽出できます。
interface LabeledContent {
label: string;
content: string;
}
命名規則のすすめ
複数のコンポーネントを組み合わせてCMS管理する場合、命名規則がバラバラだと管理がつらくなります。以下のような命名ルールを決めておくと安心です。
🧱 BlockとItemの分離
-
○○Block
: 表示の単位、配列を持つ親(見た目・スタイル) -
○○Item
: 個々の中身(実際のコンテンツ)
例:
interface FaqItem {
question: string;
answer: string;
}
interface FaqBlock extends CommonStyle {
fieldId: "faqBlock";
items: FaqItem[];
}
🎨 スタイル系共通名
textColor
backgroundColor
subColor
fontSize
-
padding
/margin
🏷️ フィールドIDの命名
microCMSの fieldId
は "faqBlock"
のように 用途 + 種類 で明示的に付けておくと、あとからわかりやすいです。
まとめ
カスタムフィールドを多く定義していくと、似たような構造が頻出してきます。
それに気づいたら、「構造を共通化」して、「スタイル設定を共通の型に切り出す」ことで、CMSの設計がグッと整理されます。
以下の3点を意識すると、拡張性・可読性の高い設計ができます:
- 共通構造は reusable interface に
- スタイル系プロパティは共通化
- 命名ルールは明確に分ける(Block / Item など)
microCMSは柔軟な分、設計次第で運用効率が大きく変わるので、最初にある程度のルールを決めておくと、後々楽になります。
Discussion