Как написать блок-схему Mermaid:направление, узлы и стрелки.

Направление

Первая строка называет тип диаграммы и направление. Работают и flowchart, и более старое graph.

• TD или TB: сверху вниз
• BT: снизу вверх
• LR: слева направо
• RL: справа налево

Выбирайте LR для короткого процесса, который умещается в ширину страницы, и TD для более длинного.

Формы узлов

Узел — это идентификатор, после которого в скобках при желании идёт текст. Форму выбирают скобки:

flowchart LR
    a[Rectangle]
    b(Rounded)
    c([Stadium])
    d[[Subroutine]]
    e[(Database)]
    f((Circle))
    g{Decision}
    h{{Hexagon}}
    i[/Parallelogram/]

Узел без скобок просто показывает свой идентификатор. Позже на узел можно сослаться только по идентификатору, поэтому форма и текст пишутся один раз.

Связи и подписи

Связи соединяют два узла. Вид стрелки показывает вид соединения:

flowchart LR
    A --> B
    B --- C
    C -.-> D
    D ==> E
    E -->|label| F
    F -- text --> G

• --> стрелка, --- линия без наконечника
• -.-> пунктирная стрелка, ==> толстая
• -->|label| или -- label --> ставит текст на связь
• A --> B & C связывает один узел с несколькими, а A --> B --> C строит цепочку связей

Добавьте дефисов, чтобы связь стала длиннее, например ---->, если узлу нужно больше места.

Подграфы

Подграф группирует узлы в блок с подписью. Он начинается со слова subgraph и заканчивается словом end:

flowchart TD
    subgraph client [Client]
        A[Browser] --> B[App]
    end
    subgraph server [Server]
        C[API] --> D[(Database)]
    end
    B --> C

Слово в скобках — это название, а слово перед ним — идентификатор, на который можно ссылаться. Внутри подграфа может быть своя строка direction LR, но направление игнорируется, если узел внутри связан с чем-то снаружи.

Полный пример

Соберём всё вместе: небольшой процесс выпуска релиза с решением, возвратом назад и сгруппированным шагом:

flowchart TD
    A([Start]) --> B[Write the change]
    B --> C{Tests pass?}
    C -->|No| B
    C -->|Yes| D[Open a pull request]
    subgraph review [Review]
        D --> E{Approved?}
        E -->|No| B
    end
    E -->|Yes| F[(Merge)]

Читайте сверху: форма «стадион» отмечает начало, ромбы — вопросы, стрелки с подписями — ответы, а рамка вокруг двух узлов — ревью. Если называть каждое решение вопросом, а каждую стрелку его ответом, блок-схема читается без объяснений.

Комментарии и стили

Строка, начинающаяся с %%, — комментарий, и она не рисуется. Чтобы раскрасить узлы, определите класс и примените его:

flowchart TD
    %% the happy path
    A[Start]:::good --> B[Done]:::good
    classDef good fill:#d4f4dd,stroke:#2d7a46

Не увлекайтесь оформлением. Большинство блок-схем читается лучше с меньшим числом цветов, а стили могут выглядеть по-разному в светлой и тёмной темах.

Частые ошибки

• Слово end строчными буквами как текст узла ломает диаграмму. Пишите End или возьмите текст в кавычки.
• Идентификатор узла, начинающийся с o или x сразу после связи, например A---oB, читается как связь с кружком или крестом. Добавьте пробел или напишите с заглавной.
• Спецсимволы в подписи. Скобки, круглые скобки и двоеточия нужно брать в двойные кавычки: A["Save (draft)"].
• Нет первой строки. Без flowchart TD ничего не нарисуется.
• Слишком много узлов. Блок-схему из тридцати прямоугольников трудно читать. Разделите её или используйте подграфы.

Если диаграмма не получилась, Mermaid показывает сообщение об ошибке, а текст остаётся в вашем файле, чтобы его исправить.

Как это нарисовать

Блоки Mermaid в Markdown-файлах рисует GitHub и DotMD: офлайн, в светлой или тёмной теме под цвет страницы. В редакторе команда Insert → Diagram вставляет в документ рабочую блок-схему, а предпросмотр перерисовывается по мере набора. В том же руководстве рассказано о диаграммах последовательности, классов, состояний, ER и Ганта. Сам синтаксис ограждения описан в статье блоки кода в Markdown.

Вопросы о блок-схемах Mermaid

Другие вопросы