Closed dnlmc closed 1 year ago
Hey, yes I have been thinking about this. Currently the code is fully replaced on any UI edits. I will explore possible solutions to this such as differential updates or storing the information on initial parse and replacing it on re-render even though it doesn't exist yet in the UI diagram. Not quite sure how I will tackle making sure comments sit above the correct line either.
@ted-marozzi Nice! I thought about that too, might not be too terrible if some lines get shifted around a bit after UI edits, easier to fix than losing them entirely!
I'm sure as diagrams get too complex, substantial edits via UI will be too fragile, but an 80-20 solution would probably go a long way. And I think one of my major use-cases for this tool will be as a quick start & rapid iteration to get the initial structure & substance laid out, then doing final touches via code (but would be nice to be able to do it all in the same tool).
Just being able to paste in starting templates from code examples has been huge! (& will make maintaining / updating / restructuring diagrams in the future so much easier)
Yeah that sounds good, I have just pushed through initial support for preserving theme. Will continue to add more things to preserve on UI edits.
Okay, after investigating I found its not trivial to just ignore lines or elements that I haven't implemented support for. I implemented this for comments and directives because there isn't another obvious way but it requires essentially reimplementing the parser that mermaid js implements. What I can do though is implement support for every feature at the code (and image level), where they will persist in the code and show in the rendered image but not in the UI, then later on, if possible, I can add support at the UI level.
Directives (e.g %%{init: { "theme": "forest" }}%% ) are an example of a feature that I have implemented now at the Code level (they won't be removed from the code and the image will respect them) but not the UI (yet).
Here is a list of things I think I need to support, let me know if I missed any: Support Code
Support UI
I will work my way through the Supporting Code at each level first then this issue should be resolved.
@ted-marozzi ah damn, was worried that might be the case!
but great to see you already making progress!
that list looks complete to me (wish the docs pages had ToCs....might see if they are open to a PR for that), most excited for Subgraphs, tooltips & edge-node styling !
They have been very welcoming and active on prs from my experience. :) I will prioritise those then
I have been working on supporting infinitely nested subflows 😵💫, here is a preview link if you want to test. It doesn't handle all cases yet.
I'm looking to build up a set of diagrams to test with so if you have any diagrams that don't render correctly after UI interaction it would be great if you could send me the text (subflow related or not).
@ted-marozzi haha nice! altho infinite seems a bit overkill 😁
I just tested all the examples from https://mermaid.js.org/syntax/flowchart.html#subgraphs & they seem to work! Altho hard to tell what is "right" after e.g. making changes via UI.
I actually have some use cases for this though so will give them more of a spin & let you know how it goes !
Yeah maybe it was, but I like to tackle the hard things first, because the hard things are what require rewrites. Speaking of I had to rewrite the code gen engine but its come out much cleaner and faster. I am pretty confident that the nested subgraphs is correct now, and also the generated code should have less redundant information so that has been pushed to prod. :)
Way too much recursion for one day ahah onto some easier things tomorrow!
@ted-marozzi hah no doubt, I was really just saying "infinitely" nested might be overkill lol
but nice, thanks for all your work on this! I just kicked the tires for a good while & subgraphs seem to be mostly working great!
but seeing a few bugs:
A --> B --> C
to A --> B
& B --> C
. Not sure this ever actually changes the diagram itself, but makes the code more verbose & makes logical pathways less obvious in the code.I noticed all of these happening even when I don't interact with the UI, but just seems to refresh itself
here's the code for the diagram i'm working with:
flowchart TB
GH("Github") --> AWS("AWS")
AWS --- SENTRY("Sentry")
GC("Glue Code") -.-> AT("Airtable")
GC -.-> GS("Google Sheets")
GC -.-> SQ("Square")
SQ -.-> AT
GC -.-> STRIPE("Stripe")
STRIPE -.-> AT
PP("Paypal") -.-> GC
PP -.-> AT
DB("Donorbox") -.-> GC
DB -.-> AT
GCP("Google Cloud Platform") -.-> GC
subgraph CLOUD
direction TB
AWS --- HEROKU("Heroku")
AZURE("Azure") --- HEROKU
GCP
end
subgraph CODE
direction TB
GC --> GH
GH --- SENTRY
GH --- GC
end
subgraph DATA
direction TB
AT -.-> GS
AT --> DS("Data Students")
DS --> LS("Looker Studio")
GS --> LS
end
subgraph DONATIONS
direction TB
DB --> STRIPE
DB --> PP
SQ
end
@ted-marozzi hah no doubt, I was really just saying "infinitely" nested might be overkill lol
oh ahaha never know if someone might paste in an infinite diagram 🤭
but nice, thanks for all your work on this! I just kicked the tires for a good while & subgraphs seem to be mostly working great!
Thank you for the donation and beta testing, its super valuable!
but seeing a few bugs:
- it seems to keep wanting to kick some nodes out of subgraphs, seemingly related to the nodes having no links defined WITHIN the subgraph (but I need to list them under their subgraph so they shows up in the right group). e.g. GCP & SQ in the code below
Pushed out a quick fix for this, subgraphs will get defined before links
- it doesn't seem to like chains of links longer than 2 nodes, e.g. it will break up
A --> B --> C
toA --> B
&B --> C
. Not sure this ever actually changes the diagram itself, but makes the code more verbose & makes logical pathways less obvious in the code.
Yeah, the current code generation produces the simplest but most verbose code. I will open a seperate issue to track options for this. It shouldn't ever change the diagram.
- Similarly, it seems to duplicate some lines / link definitions sometimes, not sure what triggers this
That sounds like a bug! If you hit this one again, send a diagram/link.
- I can't really use the UI once i start interacting with the code editor (e.g. to organize nodes logically to make them easier to work with, even tho they won't necessarily be rendered this way by Mermaid), because the whole layout gets reset in the UI after each code edit. This is a minor gripe, but would be nice to have the UI layout persist through editing
Yeah, i'll open another issue to think about what I can do here.
I noticed all of these happening even when I don't interact with the UI, but just seems to refresh itself
The trigger for refreshing is unfocusing the code editor. One day i'll draw a mermaid diagram on how it works and it will make more sense of why things happen.
Pro tip: A good way to test for a bug is paste a diagram into the code editor, then scroll to the image. Once you click on the image, the editor will unfocus and the code will be recomputed, if there is no bugs, the code will get reformatted but the image should stay the same.
@dnlmc I believe its should be all implemented, let me know if the code is removing any diagram features it shouldn't be! If all good, I will close this issue, and eventually implement real support for the features.
@ted-marozzi amazing, thanks!!! I've been tied up for a few days but just did a few tweaks & everything seems to be working so far. will do more kicking the tires soon & report back!
Closing for now, i'll reopen if you hit an issue :)
Is your feature request related to a problem? Please describe. When the code editor isn't sure how to parse some code, or the feature isn't yet supported in the UI (e.g. subgraphs or tooltips or diagram themes), it initially renders correctly in the Export preview, but then the unsupported code gets stripped out / overwritten when you interact with the UI (or export as image).
Describe the solution you'd like Ideally, code for unsupported features, but that is valid Mermaid code, would still persist in the Editor (even if not reflected in the UI editor), & not be stripped when interacting with the UI or other elements. E.g. if a theme is added & the parser can correctly recognize & render it, it should not be overridden by further UI edits. If a UI edit invalidates the code then a parse error can be raised in the Export window for the user to resolve, or the code will just become inactive (e.g. a tooltip which no longer refers to a valid node).
Describe alternatives you've considered This issue would also be resolved by implementing support for all Mermaid features in the UI, but the solution above could be a fallback until that time -- or indefinitely, assuming some features might be much more difficult or impossible to support via UI.
Additional context The proposed solution would unlock full Mermaid capabilities via code, while maintaining the ease of use & rapid iteration of the core UI supported elements (structure, layout, labelling, etc). Not sure how complex this will be, as I assume the UI is just fully replacing the code in the Export editor with each change (& will obviously not include unsupported elements). But perhaps there is a way to ignore preexisting unrecognizable (but valid) code.