概要
どんなときに使うか
独立した URL を持つページをプラグインから提供するときに使います。
たとえば、次のようなページです。
- Garden Explorer
- プラグインのレポート画面
- プラグインが生成する一覧ページ
- 独自の検索・閲覧ページ
一方、記事本文の中へ何かを表示するだけなら、ページ種別は必要ありません。
Diagram source
flowchart TD
Q{"プラグインが何を表示する?"}
Q -->|"独立したURLを持つページ"| Page["pageTypes"]
Q -->|"記事本文へ埋め込む"| Renderer["renderers"]
Page --> P1["例: /explore"]
Page --> P2["例: /report"]
Renderer --> R1["Canvas"]
Renderer --> R2["Bases"]
Renderer --> R3["Excalidraw"]
Canvas、Bases、Excalidraw のように記事本文へ埋め込む機能は renderers を使います。
役割の分担
プラグインがページ全体を所有するわけではありません。役割は次のように分かれます。
| 層 | 責務 |
|---|---|
| Core | ページ種別の取り決め、検証、URL の列挙、解決、競合の検出 |
| プラグイン | ページ種別 ID、公開 URL、フレームワークに依存しない HTML 本文 |
| HonoX Integration | 共通ルートの解決、SSG パラメータの生成 |
| サイトアプリケーション | ルート、HTML 文書の枠組み、メタデータ、HTML の描画 |
| テーマ | デザイントークンと安定した CSS フックによる見た目 |
全体では次のような関係になります。
Diagram source
flowchart LR
Plugin["プラグイン<br/>ページを提供"]
Core["Core<br/>ページの取り決めと解決"]
Integration["HonoX Integration<br/>ルーティングとSSG"]
Site["サイト<br/>HTML文書と描画"]
Theme["テーマ<br/>CSS"]
Plugin --> Core
Core --> Integration
Integration --> Site
Theme --> Site
ルートと HTML 文書の枠組みは、サイトアプリケーションが所有します。プラグインはページの内容を提供しますが、次のような HTML 文書全体を生成するわけではありません。
<html>
<head>
...
<body>
共通のルートへまとめる
以前は、独立ページを持つプラグインごとに、サイト側へ専用のルートが必要でした。
Diagram source
flowchart LR
Request["リクエスト"]
Route["プラグイン専用ルート"]
Component["プラグイン専用コンポーネント"]
Frame["サイトのHTML文書の枠組み"]
Request --> Route
Route --> Component
Component --> Frame
この方式では、プラグインを追加するだけでは動かず、サイトアプリケーションのルートも変更しなければなりません。プラグインとサイトが強く結び付いてしまいます。
そこで、すべてのプラグインページを共通のルート解決処理へ集めます。
Diagram source
flowchart LR
Request["リクエスト"]
Catch["すべてを受け取るルート"]
Resolver["resolveRiebeckiteRoute"]
Page["プラグインページ"]
Content["コンテンツ"]
Redirect["リダイレクト"]
Request --> Catch
Catch --> Resolver
Resolver --> Page
Resolver --> Content
Resolver --> Redirect
新しいプラグインページを追加しても、HonoX のルートを増やす必要はありません。