Mermaid.js ブロック図構文 & グリッドレイアウトガイド

ブロック図は、複雑なソフトウェアアーキテクチャ、ハードウェアプラットフォーム、または組織モデルを表現するために使用される構造化レイアウトエンジンです。Mermaid.jsにネイティブに導入された、blockエンジンはレイアウトキャンバスを絶対的な数学的グリッド行列として扱います。これにより、列の整列、独立したレイアウトのネスト境界、構造的スペースブロック、明示的なエッジポートリンク設定を正確に制御できます。

グリッド行列戦略の理解

標準的な自由形式のフローチャートがレイアウトトラックを動的に推測するのに対し、ブロック図は厳密な線形座標グリッドシステムに基づいて構築されます：

• 列のしきい値：あなたはcolumnsmodifier を使用して厳密な水平限界を設定します。グリッドにブロックが満たされると、追加の要素は自動的に次の行にきれいに折り返されます。
• グリッドフィールドによるサイズ指定：デフォルトでは、各ブロックは1つの座標スロット（$1 times 1$）を占めます。明示的な列幅を割り当てることで、要素を複数のトラックに完全に跨がせるようにこの動作を変更できます。

基本構文構造

すべてのレイアウトはblock宣言ヘッダーから始まります。その後、columnsキーワードを使用して行幅容量を設定し、連続する行にブロックを宣言します。

block
  columns 3
  componentA["First Block"]
  componentB["Middle Block"]
  componentC["Right Block"]

構文リファレンス

以下の表は、ブロックインタープリターがネイティブに認識する基礎的なデータパラメータ、カスタムスタイルキーワード、構造的コンテナを分解しています。

高度な機能：明示的なブロックサイズとスペース修飾子

非対称レイアウトの場合、コロン記法の区切り記号を使用して、明示的な水平サイズメトリクスを標準ブロックまたはスペース区切りに直接渡すことができる。(:幅)。これにより、要素が複数のグリッド位置にきれいに広がるよう強制される。

block
  columns 4
  wideComponent["広いダッシュボードヘッダー"]:4
  leftBar["サイドバー"] space:2 rightBar["メインパネル"]

高度な機能：エッジタイプ、方向、リンクオプション

の接続はブロックエンジンでは、標準的な意味論的線と構造的レイアウトブロック矢印に分けられる。標準的な接続線は、線が要素の周りにどのように折り返されるかを規定する明示的な方向制約を指定できる。

1. 標準的な線接続子

ブロック接続は標準的なリンク演算子を使用する（-->, --, <-->). ただし、括弧内に方向または修飾子を追加することで、ルーティングを制御できます：

• A --> B : 要素Aから要素Bへ向かう標準の方向性ラインを描画します。
• A -- x B : 「X」マークで終了する接続パスを描画し、遮断されたパスを示します。
• A -- o B : 開いた円形のコネクタドットで終了する接続パスを描画します。

2. ダイナミックレイアウトブロック矢印

ブロック矢印は、実際の行予算行列内の実際の座標インデックスブロックを占める、実際のレイアウトコンポーネントとして扱われます。物理的なフローパスをマッピングするために、より大きい・より小さい構文プロパティを使用します：

block
  columns 3
  producer["データプロデューサ"]
  midArrow<["トランスフォームトラフィック"]>(right)
  consumer["データコンシューマ"]

高度な機能：サブブロックマトリクスのネスト（複合グループ化）

The block:idラッパーは、分離されたレイアウトボックスコンテキスト環境として機能します。アプリケーショングループコンテナは、サブブロック内に独自の水平列数を設定でき、複雑なコンポーネントを密にグループ化しながら、グローバルな親キャンバステンプレートグリッドの間隔に影響を与えません。

block
  columns 2
  rootGateway["グローバルゲートウェイ"]
  
  block:microserviceCluster
    columns 3
    auth["認証ノード"]
    api["コアAPI"]
    worker["ワーカーエンジン"]
  end

実世界のブループリント：キャッシュ付きのマルチティアインフラ構造

この包括的で、複数行構成のブループリントは、クリーンなプロダクショングレードのインフラ構成を示しています。3列の処理グリッドレイアウトを確立し、構造的なspace要素を使ってデータベース層を分離し、太い下向きのblockArrow、およびネストされた「block:id ... end」複合ラッパー。

block
  columns 3

  %% 行1：エントランスサービス
  dnsClient(("Web Client"))
  loadBalancer["エッジロードバランサー"]
  space

  %% 行2：マイクロサービスへの接続フロー
  space
  downRoute<["トラフィック転送"]>(down)
  space

  %% 行3：複合アプリケーション環境クラスタ
  block:appCluster
    columns 2
    authService["認証"]
    apiEngine["コアAPIワーカー"]
  end
  space
  database[("PostgreSQL DB")]

  %% 明確なマトリクス間構造ラインの整合を確立
  loadBalancer --> appCluster
  appCluster --> database

一般的な構文の落とし穴とシステム制約

正確なグリッドマトリクス地図をコンパイルする際には、パースエラーを防ぐために以下の検証チェックを心に留めてください：

• 列予算の厳格化：列数を正確に把握してください。列数をcolumns 3と指定し、行に4つの連続するブロックを記述すると、4番目のブロックは自動的に行2に移動し、予期した左から右への接続経路を破壊する可能性があります。
• 複合ネスト順序：「block:id」で内部コンテナを構築する際は、後続の要素を宣言する前に、必ず「end」キーワードを独立した行に使用して、サブグリッドワークスペースを閉じる必要があります。ブロックを閉じない場合、図の構築が停止します。
• ブロック矢印ターゲットの制限：ブロック矢印の後に括弧で囲まれた方向プロパティ（例：(up), (down)）は、システムキーワードと完全に一致する小文字のリテラルでなければなりません。方向を大文字にすると、処理エラーが発生します。
• ラベル境界衝突：標準のフローチャート形状デコレーター（括弧()による丸ボックスや波かっこ{} ダイヤモンド）は完全にサポートされています。図形内のすべての表示テキストラベルが、文字の除去を避けるためにクリーンな二重引用符を使用していることを確認してください。