subgraph direction not applying

[MathieuJC]

Describe the bug
The subgraph direction features doesn't work anymore

To Reproduce
Steps to reproduce the behavior:

1. Create a graph
2. Add subgraphs with different directions

Expected behavior
subgraph should have different directions then the main graph

Screenshots

Code Sample
live editor.

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Chrome
• Version: 96.0.4664.45

Additional context
Feature merge with following PR: #2271

[MathieuJC]

After further investigation, I realize that subgraph directions are not working correctly when the subgraphs interacts with each other.

removing the arrow from C to D "solves" the problem

[knsv]

You are right, the direction only works when the subgraph is "isolated".

[Albert-King]

I'm willing to send more codes to show this bug:

flowchart TB

subgraph master
direction TB
etcd<-->kube-APIServer<-->kube-controller-manager
kube-APIServer<-->kube-scheduler
end

subgraph nodeCluser
	subgraph node1
	kubelet
	kube-proxy
	docker
	end
	style node1 fill:red
	
	subgraph node2
	end
	
	subgraph node3
	end
end

in this case, two subgraphs are side by side, while i want to place master at the top of nodeCluser, but the code 'flowchart TB' is not work.
And, in subgraph node1, three boxes occlude the text 'node1'

windows10
mermaid in typora v8.11.0

[nikmd23]

I ran into this bug today as well.

I'd love to have it be fixed - of course. 😁

Thanks for the wonderful project. I'm very excited to see it being integrated into GitHub.

[iamkarlson]

This is really annoying bug for big diagrams, please prioritize.

[sjoerd-vogel]

I also confirm this and find it rather annoying.

[olmigs]

@MathieuJC Have you tried removing the line C --> D{Something ?} and replacing it with a line after your subgraph definitions like Flow --> API?

live preview

[jdrusso]

@MathieuJC Have you tried removing the line C --> D{Something ?} and replacing it with a line after your subgraph definitions like Flow --> API?

live preview

I can confirm this works for me, but it would still be great to be able to preserve relations between elements in different subgraphs.

[MathieuJC]

@olmigs

Changing from targeting a node to targeting a subgraph doesn't fix the issue as the intent is different.

I would use "graph" targeting to represent something like "System A uses System B"
The intent here is to represent "This element of System A is going to use this element of System B"

here's another live preview that might show the issue in a more concrete way (mermaid v. 9.1.1)

Result:

Expected

[olmigs]

So like this preview ? Looks like either option works.

[MathieuJC]

@olmigs

You're right, putting the "links" inside the subgraph fixes it for that case.

But reusing the exemple I gave when I reported the issue 6 months ago, you can see that the "Flow" chart is declared as being Left to Right, but displayed as Top to Bottom, and the "API" graph is declared as Bottom to Top, but displayed as Top to Bottom

I think I expected a result like this:

In other words, mermaid disregards the defined direction to display things it thinks is the best.

slightly modified preview used for the image above

[olmigs]

The key here is the declaration of the diagram type. See the first line of this preview
I believe we need to declare like flowchart LR or else mermaid defaults to TD/TB

[jdrusso]

That still doesn't give the expected behavior described by @MathieuJC . The API subgraph in your preview is display LR, despite being specified as BT.

[nikhiltitus]

I have a use case similar to the one @MathieuJC has. Can we have this fixed. Can the direction in subgraph be maintained even when we connect nodes between two subgraphs.

[taranlu-houzz]

I am also running into this issue.

[ferrieux]

As this group of issues is still unassigned and keeps eliciting zero reaction from the devs, despite a direct link to user adoption (or is the phrase "show stopper" ambiguous ?), my gut reaction is to run away from this abandonware.

My primary use case being within Gitlab's Markdown, I'm starting to consider an alternative supported there, kroki.
But I would like to avoid doing the same mistake twice, investing much time in critical graphs on yet another dying platform.

Have you, ladies and gentlemen, got some insight on kroki, either in terms of usability or prognosis ?

[taranlu-houzz]

@ferrieux Yeah, I am also quite disappointed/frustrated by these issues as well. That being said, this project is pretty wide in scope, and mermaid supports a bunch of different kinds of graphs, so I can see how they are probably only able to focus effort in a particular area at any given time.

I do agree that it would be nice if it could be acknowledged that this is a very serious issue though. Maybe I am missing something, but it seems like the flowchart graph type would be pretty widely used, and as it is right now, it is not usable for anything other than very simple graphs in my opinion.

[kc-sn]

I do agree that it would be nice if it could be acknowledged that this is a very serious issue though. Maybe I am missing something, but it seems like the flowchart graph type would be pretty widely used, and as it is right now, it is not usable for anything other than very simple graphs in my opinion.

I spent close to a day building a fairly large graph with dozens of entities and multiple subgraphs and elements within linking each other with the assumption that I could come back later and declare how subgraph elements should be ordered/rendered.

I was wrong.

My assumption is that this isn't an easy fix, but I'm guessing if someone took the time PR a solution which doesn't break anything they'd likely accept it. I'm assuming like everyone else in this thread, while it's nice if this would get fixed, I don't have the time/bandwidth to dive in and make an attempt. Meanwhile, I'll just 👍 this issue and hope some wandering soul will hear our plight.

[lems3]

I'm adding my voice here to this issue. Is there a way to add a link to this issue in the documentation with a note about the current limitation ? For us it's not a big deal, but I did lost some time over this. And it could bring some attention to this issue so hopefully someone with time can try to fix it.

[knsv]

We should fix this.

[tkrenn-hc]

I'll speak up too. Would love to see this fixed. Great tool but useless for me while this functionality is broken.

And thanks @knsv for taking it on!

[vorishirne]

So much an issue, that large diagrams just scatter like a broken piece of glass. Please fix this amazing product

[knsv]

A clarification is in order here. The direction statement affects the layout of a subgraph but only as long as it does not have any links leading in or out of it. The reason for this is that if you have links in or out then the graph of nodes is not longer the set of nodes in the subgraph but actually the set of nodes of the parent container including the ones in the subgraph. One can see it as that the direction of the container gets injected in the subgraph with a link. This will be clarified in the documentation.

This is it for this ticket. It is not simple bug, then we would fix it, but a theoretical issue. I understand if that is disappointing as this is a still a problem. However ... layout issues in big graphs is an issue which is being looked it. Next on my list as a matter of fact. There are two different tracks that can help:

• Work arounds for the current layout algorithm, dagre. For instance the addition of in links that are "invisible" and used only for some layout effect etc.
• The second track is adding additional layout algorithms offering alternative layouts for a particular graph.

#815 Is the ticket for the layout issues. We are in the process of making Mermaid smaller by decoupling the graphs, this opens up new possibilities in this area.

[felixsanz]

this is a bug not a theoretical issue. for me it makes mermaid unusable as you can't group elements and express the relationship between them. This is my first usage of mermaid and probably my last one too

[tirerocket]

Definitely a blocker for my flowcharts, would really like to see the fine-grained control over subgraph direction. Rooting for you @knsv !

[iamkarlson]

Would it be possible if any of the contributors pick this up? @knsv or @sidharthv96 I rarely call people out in opensource issues because I do realize tremendous amount of work you are doing volunteering in such projects. However, I believe that this is core functionality of this project that is a major blocker for many use cases. could you perhaps anyhow prioritize it please?

[tirerocket]

Can we reopen and classify this as a feature request please? Based on the activity in this thread, there's a lot of people who are looking for this functionality @sidharthv96 @knsv @jason-curtis

[sidharthv96]

As @knsv stated here, this issue seems to be a limitation of dagre. But, it is also not working in flowchart-elk, so, we think that should be fixed.

PRs are welcome!

[AndreiPashkin]

ELK engine does not support that: kieler/elkjs#26

[maikol-solis]

Hi!, I'm having the same issue. I tried using mermaid instead of graphviz for a particular diagram with subgraphs, but it's impossible due to this limitation. I will keep using graphviz until this is fixed.

Best.

[rui-costa]

Forcing direction doesn't enforce direction

Code

---
title: Test
---
flowchart LR
    subgraph API Layer 
    direction LR
    i1([Item 1])
    i2([Item 2])
        subgraph Services
            direction LR
            i3[Item 3]
            i4[Item 4]
            i5[Item 5]
            i6[Item 6]
            i7[Item 7]
        end
    end

Generated Image

---
title: Test
---
flowchart LR
    subgraph API Layer
    direction LR
    i1([Item 1])
    i2([Item 2])
        subgraph Services
            direction LR
            i3[Item 3]
            i4[Item 4]
            i5[Item 5]
            i6[Item 6]
            i7[Item 7]
        end
    end

[WilliamBonvini]

Hi everyone, I think this issue deserves attention as well. This functionality is key to many of us.
I discovered Mermaid only recently. I think it is a fantastic project, but this bug is definitely clipping my wings!