ホストクロームバインディング

パッケージ所有ルートの主要クローム、名前付きヘッダー項目、コンテンツへホスト側の実装を注入する。

プロジェクトで packageOwnedRoutes: true を設定すると、@takazudo/zudo-doc がドキュメントルートを自前で注入し、プロジェクト側はほぼ空の pages/ ディレクトリだけを持つことになります。これは便利な反面、通常であればプロジェクト固有のレンダリングを差し込むホストファイルが失われます。ホストクロームバインディングはそれを取り戻すための継ぎ目です。型付けされた小さなスロット群（ChromeHostBindings）を通じて、コンポーネントをエジェクトすることなく、パッケージ所有のクロームにホスト独自のコンテンツやコーラブルを注入できます。

このページでは、6つの主要クローム置換、名前付きヘッダー右コンポーネント、docContentHeaderExtras と homeExtras のコンテンツ継ぎ目、そしてすべてのバインディングを注入ルートと自己完結型ルートへ届ける settings.chromeBindingsModule を扱います。

ChromeHostBindings 型

ここで説明する継ぎ目はすべて ChromeHostBindings インターフェースのフィールドで、@takazudo/zudo-doc/factory-context からエクスポートされています。

import type { ChromeHostBindings } from "@takazudo/zudo-doc/factory-context";

すべてのフィールドは任意です。省略したスロットは、継ぎ目導入前の挙動をバイト単位で再現するパッケージデフォルトにフォールバックするため、部分的なバインディングオブジェクトでも常に安全です。

ChromeHostBindings は、クローム自身の呼び出し地点が内部で必要とする広い構造的な形状で各スロットを型付けします。実際の狭い型を持つコンポーネントやコーラブルをそのまま直接代入する — あるいは代入をコンパイル可能にするために as／as unknown as キャストに頼る — と、本当に重要なチェック、すなわち「渡した値がクロームから渡されるプロパティを実際に受け取れるかどうか」が消えてしまいます。代わりに @takazudo/zudo-doc/chrome-bindings からエクスポートされる defineChromeBindings でバインディングを組み立ててください。その入力型 ChromeBindingsInput は、各スロットの実際の呼び出し地点が渡す正確なプロパティや引数を宣言しているため、クロームが決して渡さないプロパティをコンポーネントが要求している場合はコンパイルエラーになります（#2674 のドリフト検出チェック）。広い ChromeHostBindings 形状は、あなたが気にする必要のない内部の単一のワイドニングステップによって生成されます。

配信チャネル: chromeBindingsModule

packageOwnedRoutes: true ではクロームがパッケージ内部で組み立てられるため、バインディングを渡すためのホスト側の呼び出し地点が存在しません。プラグインがルートへ渡すルートコンテキストはシリアライズ可能なデータのみ（settings、translations、タグ語彙）を運ぶため、関数やコンポーネントを運ぶことはできません。このチャネルはその制約を回避します。コーラブルそのものをシリアライズするのではなく、それらをエクスポートするモジュールへのパスをシリアライズするのです。

zudoDoc() 設定の chromeBindingsModule に、defineChromeBindings で組み立てた名前付き chromeBindings エクスポートを持つモジュールを指すプロジェクトルート相対パスを設定します。

export default defineConfig(
  zudoDoc({
    // packageOwnedRoutes defaults to true
    chromeBindingsModule: "./src/chrome-bindings.tsx",
  }),
);

import { defineChromeBindings } from "@takazudo/zudo-doc/chrome-bindings";

export const chromeBindings = defineChromeBindings({
  // ...seams go here (see below)
});

ビルド時にルートプラグインが chromeBindings を再エクスポートする仮想モジュールを登録し、注入されたクロームシムがそれをクロームファクトリへスプレッドします。文字列パスはシリアライズ可能なので、「ルートコンテキストはデータのみ」というルールは依然として保たれます — 異なるのはローダーのソースだけです。

名前付きヘッダー右コンポーネント

headerRightItems はシリアライズ可能なままです。カスタムコンポーネント項目には文字列名だけを置き、呼び出し可能なレンダラーは chromeBindings.headerRightComponents で同じ名前へ登録します。

zudoDoc({
  chromeBindingsModule: "./src/chrome-bindings.tsx",
  headerRightItems: [
    { type: "link", href: "/status", label: "Status" },
    { type: "component", component: "release-badge" },
    { type: "component", component: "search" },
  ],
});

import { defineChromeBindings } from "@takazudo/zudo-doc/chrome-bindings";

export const chromeBindings = defineChromeBindings({
  headerRightComponents: {
    "release-badge": ({ item, index, lang }) => (
      <a
        href={`/${lang ?? "ja"}/releases`}
        data-component={item.component}
        data-position={index}
      >
        v4
      </a>
    ),
  },
});

レンダラーはシリアライズ済みの item、0始まりの index、ロケール、GitHub 値、組み込み子スロット、カラーモード／ロケールのゲートを受け取ります。組み込み名（theme-toggle、language-switcher、version-switcher、github-link、search）は予約済みです。未知の名前や予約名の上書きは、黙って消えるのではなく、設定位置と修正方法を含むエラーになります。

ルートコンテキストを通るのは項目名だけで、headerRightComponents 自体はホストのコーラブルモジュールに残ります。ほかの bindings モジュール内コンポーネントと同様、静的なアイランド登録経路も持たない限り SSR 表示用として扱ってください。

セッション固有の island props を保持する

同一ロケール内でページを移動すると、persist されたヘッダー内の island が持つシリアライズ済み props は、デフォルトでは遷移先ページの値に更新されます。ページから導出する props にはこの動作を使ってください。一方、静的に登録したホスト island がセッション固有の props を持つ場合 — たとえば、初期カウントを次ページの SSR スナップショットで置き換えたくないバッジ — は、island のルート要素か persist されたヘッダー内の祖先要素に data-zd-props-preserve を付けます。

<div data-zd-props-preserve>
  <SessionBadge initialCount={unreadCount} />
</div>

オプトアウトの判定に使われるのは遷移前から存在する live DOM です。遷移先ページだけに属性を付けても、現在の island は保持されません。保持対象の island では data-props の更新も remount フラグの付与も行われません。persist されたヘッダー自体に data-zd-props-preserve を付けると、配下の全 island が一括でオプトアウトされます。そのため、セッション固有の props を所有する範囲だけを囲むようにしてください。

既存スロットの「取り残し」も解消する

docContentHeaderExtras と homeExtras は新しい継ぎ目ですが、ChromeHostBindings にはこのチャネルが存在する以前から、注入ルートへ届く手段がなかったスロットがいくつかありました — それらはスタブのデフォルトのまま黙って据え置かれていました。chromeBindingsModule はそれらをまとめて解消します。

つまり、docContentHeaderExtras のために作成するモジュールは、たとえば以前はホスト所有ルートでしか機能しなかったカスタムフロントマターレンダラーを登録する場所でもあります。

生成されたドキュメントルートとパッケージ所有ドキュメントルートでは、通常のオブジェクト優先順位に1つだけ意図的な例外があります。docHistory が有効な場合、静的にインポートされたパッケージ DocHistory を設定済みオブジェクトの後から重ねます。これによりクライアントアイランド登録をスキャナーから到達可能に保ち、ほかのすべての binding は維持されます。仮想ホストモジュール内だけで宣言した DocHistory は、これらのルートでは置き換えられません。

docContentHeaderExtras — コンテンツヘッダーへの注入

docContentHeaderExtras は、ドキュメントのコンテンツヘッダー内、ページの <h1> とメタ情報ブロックの間に追加コンテンツを描画します。これはページエントリを受け取ってレンダリング可能な出力を返すレンダラーであり、プロパティから再導出するのではなく、現在のページのフロントマターを自然にキーとして扱えます。

docContentHeaderExtras?: (args: {
  entry: DocPageEntry;
  slug: string;
  locale: string;
  isFallback?: boolean;
  version?: string;
}) => unknown;

よくある用途は、カスタムフロントマターフィールドから導出するティアバッジです。フロントマターで tier: core または tier: opt-in を宣言するページに対して次のように書けます。

import { defineChromeBindings } from "@takazudo/zudo-doc/chrome-bindings";

export const chromeBindings = defineChromeBindings({
  docContentHeaderExtras: ({ entry }) => {
    const tier = entry.data.tier;
    if (tier !== "core" && tier !== "opt-in") return null;
    const label = tier === "core" ? "Core" : "Opt-in";
    const tone = tier === "core" ? "bg-accent text-bg" : "bg-surface text-fg";
    return (
      <span
        class={`inline-block px-hsp-sm py-vsp-2xs text-caption rounded-full ${tone}`}
      >
        {label}
      </span>
    );
  },
});

デフォルト: 未設定 → 何も描画されず、ヘッダー出力は継ぎ目導入前のヘッダーとバイト単位で同一になります。

homeExtras と HomePageView — ホームヒーローへの注入

homeExtras は、ホームヒーローのリンク行の末尾に、直前の要素（プライマリリンクや GitHub リンク）と / 区切りで、追加コンテンツをインラインで描画します — 例えば overview/GitHub のリンクと並べてブランドやソーシャルのリンクを置く用途です。

homeExtras?: (args: { locale: string }) => unknown;

export const chromeBindings = defineChromeBindings({
  homeExtras: ({ locale }) => (
    <a
      href="https://example.com/blog"
      class="text-fg underline hover:text-accent"
    >
      Read the blog
    </a>
  ),
});

優先順位: extras プロパティが勝つ

共有のホーム本体は HomePageView が組み立て、パッケージルートとホストページのどちらもこれを呼び出します。HomePageView は extras プロパティ — ホストページが直接渡す描画済みの値 — を受け取ります。両方が存在する場合はプロパティが勝ちます。

// resolved inside HomePageView as:
extras ?? hostBindings.homeExtras?.({ locale })

この非対称性は意図的なものです。ホストページは手元に JSX（値）を持っている一方、注入/バインディング経路はレンダリング時に locale 文字列しか持たず、そこから自前でコンテンツを導出しなければなりません（レンダラー）。

/ ルートのトポロジー

/ にあるデフォルトホームは、ルートプラグインによって決して注入されません — zfb が / パターンを拒否するためです（アップストリーム Takazudo/zudo-front-builder#1227）。scaffold の pages/index.tsx は @takazudo/zudo-doc/routes/index を再エクスポートする1行のファイルで、extras プロパティは渡しません。使用する注入済み / ルートが存在しないため、/ では常にホストファイルが優先されます。

• 変更していない / ホームはパッケージルートの再エクスポートを使い、extras プロパティ経由で homeExtras を受け取りません。

• 注入された /[locale] ホームは chromeBindingsModule を通じて hostBindings.homeExtras を読み取ります。

ルートホームをカスタマイズするには、再エクスポートを HomePageView を呼び出して extras を渡す自前のページに置き換えます。i18n サイトでは、その値とロケールホーム用の homeExtras が返す値を同じ内容にしてください。

Design Token Panel チャネル（designTokenPanelConfigModule）

Design Token Panel には独自のホストモジュールチャネルがあり、chromeBindingsModule とまったく同じ仕組みで動作します — 同じメカニクス、同じ「ファイルが無ければ大きな声で失敗する」挙動 — ただしクロームバインディングの代わりにパネルの設定ビルダーを運びます。

パネルは動作にホスト設定ファイルを必要としません。designTokenPanel: true にすると、注入された DesignTokenPanelBootstrap アイランドは、出荷済みのトークンマニフェストとバンドルされた Default Light / Default Dark スキームから導出されたパッケージデフォルトのビルダー（@takazudo/zudo-doc/design-token-panel-config）を使います。これがゼロコンフィグの経路です。

パネルを完全にカスタマイズするには、designTokenPanelConfigModule に、名前付きの buildDesignTokenPanelConfig(mode) をエクスポートするホストモジュールを指すプロジェクトルート相対パスを設定します:

import type { PanelConfig } from "@takazudo/zdtp";

type PanelMode = "light" | "dark";

export function buildDesignTokenPanelConfig(mode: PanelMode): PanelConfig {
  // return a mode-scoped panel config (spacing/font/size/color tiers)
  // ...
}

ルートプラグインは3番目の仮想モジュール（virtual:zudo-doc-design-token-panel-config）を登録し、あなたのビルダーを re-export します。chromeBindingsModule と同様、設定を通じて移動するのはパスだけで、ビルダー自体はモジュールグラフ経由でインポートされます。

chromeBindingsModule との違いで知っておくべき点が2つあります:

• デフォルトは空オブジェクトではなくパッケージビルダーです。 設定が無い場合、ローダーはパッケージデフォルト（完全に動作するパネル）を re-export します — フォールバックすべき意味のある「空の」ビルダーは存在しません。

• スキャナー到達可能性がこのコントラクトの一部です。 実際の DesignTokenPanelBootstrap アイランドは（設定仮想モジュールを経由せず）パッケージのクロームによって静的にインポートされるため、常に zfb のアイランドスキャナーから到達可能です。チャネルを通じて移動するのはパネル設定のデータ（モードスコープのビルダー）だけであり、これがクロームバインディングのアイランドがハイドレートしない注入ルート上でも、カスタマイズされたパネルがハイドレートする理由です。

• この設定がある間、自己完結型の pages/ スタブはパネルをマウントしません。 この設定はパッケージ注入ルートでレンダリングされるページにしか届かず、パネルの設定はブラウザセッションごとに一度だけ行われます — そのため、パッケージデフォルトのブートストラップをマウントするスタブページがハードロードの入口になると、セッション全体の設定をそのページが決めてしまっていました。設定が存在する場合（かつ明示的な chromeBindings.DesignTokenPanelBootstrap が無い場合）、スタブでレンダリングされるページはパネルアイランド（およびヘッダーのパネルボタン）を一切マウントしません。注入ルートはどの入口ページからでも、あなたの設定済みパネルを受け取ります。スタブページにもパネルを出したい場合は、ビルダーを chromeBindings.DesignTokenPanelBootstrap に通してください — このバインディングはどこでも勝ちます。

同じガード規則が適用されます: 明示的な空文字列、存在しないファイル、ディレクトリパスは、プラグインのセットアップ時に解決済みパスを明示して大きな声で失敗します。storagePrefix: "zudo-doc-tweak" はパッケージデフォルトで維持されるため、既存のユーザー保存は引き継がれます。

関連ページ

• zudo-docのカスタマイズ — 最小→拡張のはしご。chromeBindingsModule はその6段目

• フロントマタープレビュー — このチャネルが取り残しを解消する frontmatterRenderers スロット

• 設定 — zudoDoc() の完全なフィールドリファレンス

• Design Token Panel — このチャネルが設定するパネル UI