Color mode

概要

どんなときに使うか

独立した URL を持つページをプラグインから提供するときに使います。

たとえば、次のようなページです。

  • Garden Explorer
  • プラグインのレポート画面
  • プラグインが生成する一覧ページ
  • 独自の検索・閲覧ページ

一方、記事本文の中へ何かを表示するだけなら、ページ種別は必要ありません。

Diagram source
text
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
text
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
<html>
<head>
...
<body>

共通のルートへまとめる

以前は、独立ページを持つプラグインごとに、サイト側へ専用のルートが必要でした。

Diagram source
text
flowchart LR
    Request["リクエスト"]
    Route["プラグイン専用ルート"]
    Component["プラグイン専用コンポーネント"]
    Frame["サイトのHTML文書の枠組み"]
 
    Request --> Route
    Route --> Component
    Component --> Frame

この方式では、プラグインを追加するだけでは動かず、サイトアプリケーションのルートも変更しなければなりません。プラグインとサイトが強く結び付いてしまいます。

そこで、すべてのプラグインページを共通のルート解決処理へ集めます。

Diagram source
text
flowchart LR
    Request["リクエスト"]
    Catch["すべてを受け取るルート"]
    Resolver["resolveRiebeckiteRoute"]
    Page["プラグインページ"]
    Content["コンテンツ"]
    Redirect["リダイレクト"]
 
    Request --> Catch
    Catch --> Resolver
 
    Resolver --> Page
    Resolver --> Content
    Resolver --> Redirect

新しいプラグインページを追加しても、HonoX のルートを増やす必要はありません。

Local Graph

Nearby Notes