-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
Fix edge handling and arrow type #4582
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## develop #4582 +/- ##
============================================
+ Coverage 45.25% 73.46% +28.21%
============================================
Files 53 146 +93
Lines 6654 14526 +7872
Branches 32 615 +583
============================================
+ Hits 3011 10671 +7660
- Misses 3642 3710 +68
- Partials 1 145 +144
Flags with carried forward coverage won't be shown. Click here to find out more.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of issues (although they seem pretty minor, so I wouldn't mind if it's just documented somewhere that these are purposely not covered to make implementation easier):
- What if the background isn't using the CSS
background-color
property, but is instead using something likebackground: green
orbackground-image: url(...)
? - What happens if the background is a transparent color (e.g.
rgba(255, 0, 0, 0.2)
?
Ideally, we'd figure out how to stop drawing the line under the arrow head, but I'm not an SVG expert, so I've got no idea how hard that would be. It might not be worth the effort just to handle a couple of rare edge cases 🤷
Tangent: Should we add some performance benchmarks? Then we can have a reporter which comments the performance difference on each PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like Alois said, stopping the line before the arrowhead is the best solution if possible.
Co-authored-by: Alois Klink <alois@aloisklink.com>
It doesnt matter if the background isnt using a CSS property. the code is grabbing the "computed" styles - so if there is a background at all this method will pull it out. As to not drawing the line. Totally agreed. I started looking into this and have not figure out how to adjust this yet |
I think the code currently only checks for 100% white transparency, aka
I'm not sure what it does if you have partial transparencies (e.g.
If it's too difficult, this background hack should still handle 99.9% of cases. We just need to document somewhere that this is a hack, why the hack exists, and the limitations it has. E.g. something like: /**
* Finds the parent background color of an SVG element.
*
* Used to make a "hollow" arrowhead for an arrow.
*
* We can't use a transparent fill,
* because the arrow line is behind the arrowhead
* (ideally we'd stop drawing the line behind the arrowhead,
* but this is pretty complicated to do).
*
* **Limitations**:
* - If the parent background color is a partial transparency,
* the arrowhead will also be partially transparent.
* - More complicated backgrounds like pictures/animations won't work.
*/
const getBackgroundColor = (elem) => { We could always figure out not drawing the line under the arrowheads in the future. Honestly, most class UML diagrams just pick white for hollow arrows, so picking a background color is already an improvement, e.g. like: |
Ill add the comment :) |
✅ Deploy Preview for mermaid-js ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Didnt realize this was still pending |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Is it worth adding some of limitations described in #4582 (comment) into the PR description?
Co-authored-by: Alois Klink <alois@aloisklink.com>
But what determines those are the right values to use? magic numbers... |
* develop: (56 commits) chore: Fix unit tests chore(deps): update all patch dependencies chore: Update docs Update docs New Mermaid Live Editor for Confluence Cloud (#4814) Update link to Discourse theme component (#4811) Update flowchart.md (#4810) chore: remove unneeded `CommomDB` chore: Update docs "CSS" instead of "css" in flowchart.md (#4797) Update CONTRIBUTING.md Update CONTRIBUTING.md fix: typos (#4801) chore: Align with convention chore: Add JSDoc to apply in sequenceDB refactor: Tidy up direction handling chore: Fix flowchart arrow chore: Add test to verify activate chore: Update tests snapshot fix: #4691 Align arrowheads properly in sequenceDiagram ...
const str = 'classDiagram\n' + 'Class1 --|> Class02'; | ||
const str = 'classDiagram\n' + 'Class1 --|> Class2'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already support Extension --|>
and Realization ..|>
.
Wouldn't releasing this change mark the extension as a realization, changing the meaning of a lot of existing diagrams?
classDiagram
classA <|-- classB
classM <|.. classN
I am going to close this PR, and redo to take into account the fix with #4788 |
📑 Summary
Adds realization markers to class Diagram.
Resolves #3816
Resolves #1687
📏 Design Decisions
📋 Tasks
Make sure you
develop
branch