standardize info diagram definitions

[Yokozuna59]

📑 Summary

Currently, most diagrams aren't fully typed, which causes some expected behaviors.

Originally, I was planning to do that here in #4450 while migrating to the new parser, but it appears it's going to take some time since I'm not familiar with the repo structure and the current DBs and still can't figure out a way to run the parser without the language server. I guess by adding and documenting the types and functions, I would be knowledgeable about the mermaid structure and each diagram style, definition, and DB, and then I would be able to use those DBs in the new parser.

Standardize diagrams definitions by:

• Converting JS code into TS.

• Remove @ts-* comments

• Add and use defined types and interfaces.

• Add more JSDoc comments.

• Standardize Diagrams Definition:

  ---
  title: Diagram Definition
  ---
  flowchart LR
  diagram --> diagramDb.ts
  diagram --> diagramDetector.ts
  diagram --> diagramRenderer.ts
  diagram --> diagramDiagram.ts
  diagram --> diagramTypes.ts
  diagram --> diagramStyles.ts
  

📏 Design Decisions

Describe the way your implementation works or what design decisions you made if applicable.

Diagram Definition:

• DB: similar to the existing one but with types and standardizing definitions.
• Detector: similar to the existing one but with types if missing.
• Renderer: similar to the existing one but with svgDraw.js if exists.
• Diagram: contains the diagram definition with db, parser, styles, etc.
• Types: contains diagram types and interfaces for DB, styles options, etc. i.g., classTypes.ts.
• Styles (NOT SURE): Either combining it with Renderer like quadrant chart or converting it to TS like flowchart.

📋 Tasks

Make sure you

• 📖 have read the contribution guidelines
• 💻 have added unit/e2e tests (if appropriate)
• 📓 have added documentation (if appropriate)
• 🔖 targeted develop branch

[sidharthv96]

This is excellent work, long overdue!
Keep going 🚀

[Yokozuna59]

This is excellent work, long overdue! Keep going 🚀

Thanks! Well do! If you could give some feedback on JSDoc side that would be great, most of the time I just type what comes to my head so not sure if it's clear enough or not.

[Yokozuna59]

For d3 type issues, it appears that @types/d3 package isn't enough or might even have no use; we need to import the types for the specific used package, so I'll add more of those types when needed. I'm currently working on converting pie chart files, and the renderer needs @types/d3-shape and @types/d3-selection, so I'll add them and try to resolve those type errors and remove @ts-* comments.

[Yokozuna59]

I'm not sure how to assign Document d3 type to the new HTML one, there are some differences, so I can't make it a union type, it will affect the regular select('body').

If you've got a better design for this mess, let me know so I can follow it with other renders.

[Yokozuna59]

@sidharthv96 please re-review latest changes so I can uses the new types in pie chart files.

[Yokozuna59]

Should we mock infoRenderer inside __mocks__ dir? And add cy.get('svg'); to cypress/integration/rendering/info.spec.ts after each test case?

I know it has no use but just to standardize definitions.

And I'm currently working on pie chart files, should try supporting @vanilla-extract/css with it? Or just focus on converting files?

[sidharthv96]

Should we mock infoRenderer inside __mocks__ dir?

You can add it if it's required to run any tests. No need to add and maintain files just for standardizing.

---

And add cy.get('svg'); to cypress/integration/rendering/info.spec.ts after each test case?

You can actually remove all the cy.get('svg') inside tests that call imgSnapshotTest.
cy.get('svg') is already called inside imgSnapshotTest, so the direct call inside the tests are redundant.

---

And I'm currently working on pie chart files, should try supporting @vanilla-extract/css with it? Or just focus on converting files?

It's better not to mix things. I actually had that habit a while back (still do for small things 😅), but it's best to keep things separate.

[Yokozuna59]

You can add it if it's required to run any tests. No need to add and maintain files just for standardizing.

Ok.

You can actually remove all the cy.get('svg') inside tests that call imgSnapshotTest. cy.get('svg') is already called inside imgSnapshotTest, so the direct call inside the tests are redundant.

It would affect many files and be hard to review. I'll remove them when converting the test file of the diagram.

It's better not to mix things. I actually had that habit a while back (still do for small things 😅), but it's best to keep things separate.

It will be the same thing at the end; when trying to add styles, it will affect and change many files, and then it would be better to make each PR a separate diagram. But ok, I'll leave it to separate PR.

---

So is the pr ready to merged?

[mermaid-bot]

@Yokozuna59, Thank you for the contribution!
You are now eligible for a year of Premium account on MermaidChart.
Sign up with your GitHub account to activate.