Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Properly-Styled Decision Nodes in State Diagrams #1304

Open
MyriaCore opened this issue Mar 12, 2020 · 3 comments
Open

Support Properly-Styled Decision Nodes in State Diagrams #1304

MyriaCore opened this issue Mar 12, 2020 · 3 comments
Labels

Comments

@MyriaCore
Copy link

MyriaCore commented Mar 12, 2020

Decision nodes are an important part of designing UML state diagrams and activity diagrams. Even the most simple of diagrams tend to have some form of conditional. Mermaidjs, however, does not support this feature natively - the user has to use a workaround to accomplish the proper style, or ignore styling all-together.

The Solution I'd Like
PlantUml uses the following in their activity diagram syntax:

@startuml
(*) --> "Initialization"

if "Some Test" then
  -->[true] "Some Activity"
  --> "Another activity"
  -right-> (*)
else
  ->[false] "Something else"
  -->[Ending process] (*)
endif

@enduml

image

@startuml
(*) --> if "Some Test" then
  -->[true] "activity 1"
  if "" then
	-> "activity 3" as a3
  else
	if "Other test" then
	  -left-> "activity 5"
	else
	  --> "activity 6"
	endif
  endif
else
  ->[false] "activity 2"
endif
a3 --> if "last test" then
  --> "activity 7"
else
  -> "activity 8"
endif
@enduml

image

Their website notes:

By default, a branch is connected to the last defined activity, but it is possible to override this and to define a link with the if keywords.

For compatability, the if/then/else/endif syntax should definitely be adopted. However, I think we should also provide an alternate, more streamlined syntax, such as the following:

stateDiagram
    [*] --> Still
    Still -->  if "Gas Pedal Pressed?"
          --> Moving : [Yes] %% then branch
          --> [*]    : [No]  %% else branch
    Still --> Moving
    Moving --> Still
    Moving --> Crash
    Crash --> [*]

image

This way, we could maintain two syntaxes: one that's more verbose, but allows for compatability, and another that's less verbose, and meshes better with existing mermaid syntax.

Current Workarounds / Alternatives

@MyriaCore MyriaCore added Status: Triage Needs to be verified, categorized, etc Type: Enhancement New feature or request labels Mar 12, 2020
@IOrlandoni
Copy link
Member

@MyriaCore Thanks for the extense and clear issue. This is a duplicate of #1292 but we'll keep this one instead.

@MyriaCore
Copy link
Author

MyriaCore commented Mar 17, 2020

Really quick, I'd like to point out that the style for how the condition labels are handled seems to not really be set in stone. PlantUML seems to put the label near the incoming arrowhead for the decision node:

View Diagram

image

... however, uml-diagrams.com seems to think that a floating note should be used instead:

View Diagram

image

In my proposed syntax, the example render used a labelled state, mostly because I personally believe that a label close to the state itself is the more-desirable style. However, the state diagrams' style in mermaid already seems to want to be very self-contained, with minimal floating elements that are kinda just around. If this is the case, and is seen as something to be preserved, then I suggest we go with an incoming edge-label to the diamond, like as follows:

View Diagram

image

If this is not the case, then I do think a floating label would be adequate for the task at hand - like a note, but way closer to the decision node itself:

View Diagram

image

I really don't think it should be a full note, however - we could probably even use the same styling as the edge-labels. The point here is that it might not make a ton of sense to have the condition be bound to the edges themselves, rather than the decision node. If that means that the label is gonna be floating about in space, so be it.

@jgreywolf
Copy link
Contributor

@MyriaCore since you have done a lot of research into this already, would you be willing to take on the work?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants