Support specifying that two nodes should be at the same level/rank

[CAFxX]

Note: this is basically a clone of https://github.com/mermaid-js/mermaid/issues/418 that was automatically closed as stale without resolution, even though there was an acknowledgement that this was an important function to have.

Is your feature request related to a problem? Please describe.

I need a way to specify that two or more nodes should be placed at the same level/rank

For example, in the following graph I would like b and c to be on the same level

graph TD
a --> b & c
b --> d & c
c --> e & b

this currently yields something like the following graphs (notice how b and c are at different heights)

Describe the solution you'd like

I would like b and c to behave like in this diagram (notice how these two nodes are at the same height)

graph TD
a --> b & c
b --> d
c --> e

This is obviously an extremely simplified example. The real use cases have many more nodes, and being able to specify which ones should be at the same level is very important for the intelligibility of the output.

Any of these two solutions would work for me:

1. mermaid should recognize that there is no reason to put c on a lower rank than b (or vice-versa) and that therefore those two nodes should have the same rank (i.e. same height)
2. mermaid should support a way for the user to specify that two nodes should have the same rank, and place these nodes at the same level when rendering

Describe alternatives you've considered

graphviz allows to do this by specifying rank=same

I also tried with mermaid subgraphs but it does not yield a better outcome.

graph TD
subgraph x; b; c; end
a --> b & c
b --> d & c
c --> e & b

Additional context

[SpacyRicochet]

To take this one step further, I would love it to see if this also applies to subgraphs themselves.

flowchart TD

A
subgraph S1; B; C; end
subgraph S2; D; E; end
B --> C
A -- YES --> B
A -- NO  --> D
C -- YES --> D
C -- NO  --> F
D --> E
E --> F

It would be great if the subgraphs here could be on the same rank.

┌───────────────────────────────────┐
│               ┌───┐               │
│    ┌──────────┤ A │───┐           │
│  YES          └───┘  NO           │
│    │                  │           │
│    │                  │           │
│    │                  │           │
│ ┌──┼─────────┐     ┌──┼─────────┐ │
│ │  │  S1     │     │  │  S2     │ │
│ │  ▼         │     │  ▼         │ │
│ │┌───┐  ┌───┐│     │┌───┐  ┌───┐│ │
│ ││ B │─▶│ C │├─YES─▶│ D │─▶│ E ││ │
│ │└───┘  └───┘│     │└───┘  └───┘│ │
│ │         │  │     │         │  │ │
│ │         │  │     │         │  │ │
│ └─────────┼──┘     └─────────┼──┘ │
│           │                  │    │
│          NO                  │    │
│           │                  │    │
│           │   ┌───┐          │    │
│           └──▶│ F │◀─────────┘    │
│               └───┘               │
└───────────────────────────────────┘

[reedsutliff]

would love to see this feature as well.

[olivierduquenoy]

Yes, it will be a great improvement !!

[brandond]

Here for a +1 on the ability to place links between nodes of the same rank.

Just using the sample cross-connected diagram, if I want to connect nodes A and B as peers, it goes from something fairly intuitive, into complete garbage, because the layout code demotes the B node down to rank 2, and C/D down to rank 3, because of the link from A to B.

graph TD
  A --> C
  A --> D
  B --> C
  B --> D

graph TD
  A --> C
  A --> D
  B --> C
  B --> D

  A o--o B

No amount of subgraph trickery will get the desired layout.

[AartBluestoke]

trying to show the relationship between 2 groups of objects. the group subgraphs can't be put at the same height, one is "higher" than the other.

[ignamiranda]

I would also really like this feature

[ignamiranda]

Adding on to this, I understand why A --> B would have a parent-child relationship but I don't understand why A <--> B or A --- B would. It'd be a departure from the way it's been a long time, but having non hierarchical, horizontal links could be a cleaner, more intuitive solution than having a flag to declare two nodes as same rank.

[nickovs]

@ignamiranda I think that we need the ability to tag nodes as having the same rank even when they don't have a link, for a couple of reasons.

• Firstly, aside from breaking many existing diagrams, making symmetrical links force the same rank will make it much harder to control the layout of undirected graphs. There are plenty of cases where the data represents an undirected graph but you want to control the presentation anyway.
• Secondly, there are scenarios where we may want to place two nodes on the same rank but not draw a link between them and not necessarily have them closer together. While in your model you could use A ~~~ B to equalise the rank, doing that still places a "spring" between the nodes in the layout process. Being able to explicitly place two nodes on the same rank without forcing those nodes closer together would be helpful, and the intent would probably be clearer too.

[brandond]

Is there any consensus on the approach here, such that someone could actually pick this up and work on it? I keep stumbling over this in our flow diagrams.

[brandond]

cc @sidharthv96 @knsv

[eschalkargans]

Just updating the thread as not being able to rank nodes is a major limitation of mermaid diagrams.

Example: In a Top->Bottom diagram, I might need some nodes are aligned on row 1, row 2, row 3, etc, forcing the layout

The ~~~ syntax does not work.

Intuitively, I expected that subgraphs would allow such features, but the documentation itself says that when edges are coming out of a subgraph, alignments won't be applied

It would be such a nice feature to be able to rank node!

[cmdrrickhunter2]

The lack of this feature has forced me to use other tools for rendering category theory graphs. One of the most fundamental structures in category theory is the commuting square. This square is represented exactly the same in every category theory reference I've ever come across:

A   -- f -->  B
|             |
g             g'
|             |
v             v
A'  -- f' --> B'

Hence the term commuting square. Mermaid renders this as

%%{ init: {'flowchart': {'curve': 'linear' } } }%%
    graph LR;
      A -- f --> B
      A' -- f' --> B'
     A -- g --> A'
     B -- g' --> B'

which has the same connectivity, but lacks the instant recognition as a square. If I could render this the same way I can render

    graph LR;
      A -- f --> B
      A' -- f' --> B'

then the result would be usable. But category theory is far too complicated to display the graphs in a non-standard way. The graphs need to clarify the math that goes behind them. Recognizable graph patterns are essential.

[brandond]

Yeah, it's unfortunate that mermaid lacks support for something that seems so basic.