click/hover to Expand or collapse subgraphs/par

[sjackson0109]

Proposal

It would be very useful to expand or collapse SUBGRAPH sections of a flowchart diagram (or PAR sections of a sequence diagram).

Attributes including:

• CollapsedByDefault (on/off)
• Expand on hover (on/off)
• Expand on click (on/off)
• Expanded-Height (int)
• Expanded-Width (int)
• Expanded-Z-Index (int)
• Expanded-Zoom (int)
• Expanded-Opacity (int)
• Collapsed-Height (int)
• Collapsed-Weight (int)
• Collapsed-Z-Index (int)
• Collapsed-Zoom (int)
• Collapsed-Opacity (int)

Use Cases

Flow-charts showing complex sketches, auto-collapsing down to large subject areas. Click one subject area to expand, blowing up the diagram to reveal lots of sub-objects.. Diagrams become more of an user-driven navigation mechanism.

Sequence diagrams (such as the sequence of a conversation), can collapse 'conversation about X' into one parameter section. By clicking on the conversation about x - we can derrive clear and distinct two-way conversations, questions/answers...

Screenshots

No response

Syntax

Here is one I took off my blog...

If the send_mail() section was collapsable, the diagram would be nice and tidy. Those interested in understanding that section could click to expand the full SMTP transcript inside...

THIS COMPLEX THING:

sequenceDiagram
    box aliceblue Sender
        participant SendingMTA as Sending MTA
    end

    participant DNS as Public DNS

    box aliceblue Receiver
        participant ReceivingMTA as Receiving MTA
        actor RecipientMBX as Recipient's Mailbox
    end

    par check_mx()
        Note over SendingMTA,DNS: (1) DNS Resolution (MX)
        SendingMTA-->>DNS: Query for MX Record
        DNS-->>SendingMTA: Recipient's Mail Servers IPs
    end

    par send_mail()
        Note over SendingMTA, ReceivingMTA: (2) SMTP Handshake (ignoring STARTTLS)
        SendingMTA-->>ReceivingMTA: ehlo servername.senderdomain.com
        ReceivingMTA-->>SendingMTA: 250 servername.receivingdomain.com hello 1.2.3.4
        SendingMTA-->>ReceivingMTA: mail from: user@senderdomain.com

        par check_host()
            Note over DNS,ReceivingMTA: (3) SPF Authorisation
            ReceivingMTA-->>DNS: Query for SPF Record
            DNS-->>ReceivingMTA: Returns Approved IPs
        end

        ReceivingMTA-->>SendingMTA: 250 2.1.0 Sender OK
        SendingMTA-->>ReceivingMTA: rcpt to: user@receivingdomain.com
        ReceivingMTA-->>SendingMTA: 250 2.1.5 Recipient OK
        SendingMTA-->>ReceivingMTA: data</strong>
        ReceivingMTA-->>SendingMTA: 354 Start mail input. End with a period (.)
        SendingMTA-->>ReceivingMTA: subject: Test email
        SendingMTA-->>ReceivingMTA: This is a plain-text email, finishing on the next line.
        SendingMTA-->>ReceivingMTA: .
        ReceivingMTA-->>SendingMTA: 250 2.6.0 Queued mail for delivery
        SendingMTA-->>ReceivingMTA: quit
        ReceivingMTA-->>SendingMTA: bye
    end

    par store_mail()
        Note over ReceivingMTA,RecipientMBX: (X) Email Delivered to Recipient's Mailbox
        ReceivingMTA->>RecipientMBX: Store Email
    end

COULD BE COLLAPSED INTO THIS:

sequenceDiagram
    box aliceblue Sender
        participant SendingMTA as Sending MTA
    end

    participant DNS as Public DNS

    box aliceblue Receiver
        participant ReceivingMTA as Receiving MTA
        actor RecipientMBX as Recipient's Mailbox
    end

    par check_mx()
        Note over SendingMTA,DNS: (1) DNS Resolution (MX)
    end

    par send_mail()
        Note over SendingMTA, ReceivingMTA: (2) SMTP Handshake (ignoring STARTTLS)
        par check_host()
            Note over DNS,ReceivingMTA: (3) SPF Authorisation
        end
    end

    par store_mail()
        Note over ReceivingMTA,RecipientMBX: (X) Email Delivered to Recipient's Mailbox
    end

Implementation

None

[xinbenlv]

+1000000! While this was closed in 2019(#1123) as "out of scope", I really think it's within the scope.

[beliaev-maksim]

this scenario would be even more interesting for C4 models

[sjackson0109]

Re: ‘closed as out of scope’

I suggest: accept this is a feature request, from people who WANT this feature.. and not decide (on behalf of an entire community) to de-scope the ticket. Some questions: 1) - why de-scope the ticket? What is the underlying reason? At least manage our expectations. 2) - what gives you governing authority to ‘de-scope’ something? It’s a community.. communities have elected leaders.. ask one of them! 3) - why not read the ticket, look at comments from other people asking for this feature.. take the collective opinions, before drawing conclusions.

[jgreywolf]

Approved and available for someone to take on. I think it is a good idea, and wont even try to explain reasoning back in 2019 :)