feat: [State diagram] Add classDefs and classes to states

[weedySeaDragon]

📑 Summary

State Diagrams: add classDef statements and apply those via class statements to states so that styling can be applied. Works just like flowcharts.

Resolves #1952 1952 State diagrams inline color

Ex:

The framework and code put into place should make applying classDefs to notes and relations easier (next logical follow-on issues/PRs ).

Note that I have not yet updated the documentation. I want to be sure this is OK first, and then I'll do a separate issue & PR.

📏 Design Decisions

• changes were only done for -v2

• added new classDef and class statements (exactly like those in flowcharts)

State Diagrams use a different strategy for parsing and rendering than many other diagrams: generic statements are parsed, and then later turned into nodes, etc., primarily in the renderer. Because rendered states and relations were not created until rendering, there was no simple way to track which 'classes' should be applied to which states.

Thus I had to do some re-working of the stateDb extract() method and ensure the results of the extract() method were used by the renderer.

Implementation Notes:

In general, I copied much of the flowchart implementation. (Assumed that was a decent implementation.)

Should the styles (e.g. what comes after the classDef keywword) be sanitized in any way? If so, what method should be used?

• I added 2 tests to the cypress integration tests in stateDiagram-v2.spec.js

• I made a change to render() in mermaidAPI.ts : flowRenderer was hardcoded to call getClasses(text, diag) no matter what diagram was being rendered. I changed it to use the current renderer. (I also created a list of diagrams that implement classDefs since adding the state diagram made the if conditional long.)

• parsing .jison

  • I added classDef and class statements.
  • I had to reword the idStatement so that it would return the specific state stmt object
  • added a spec for parsing the classDefs and class statements

• stateDb

  • revised the extract method so it would handle the new classDef and applyClass statements
  • added classes[], styles[], and textStyles[] to each state
  • code cleanup: constants, moved globals to top of file;

• stateRenderer-v2

  • the term "node" was being used all over with different meanings. I changed the names of some to help disambiguate.
  • The diagram text was being parsed repeatedly during rendering, especially for each separate 'document' (container) section. I saved (cached/memoized) the result of statedb extract() so that if the diagram had already been parsed and info extracted, that information was used during rendering (instead of parsing and extracting it again).
  • There was a lot of duplication between the rendering methods and the stateDb extract() method. I reduced it some.
  • I pulled out many of the string literals into constants, especially in stateRenderer-v2. In addition to clean coding practices, much of this will make it easier to apply theming in the future.

• stateDiagram-v2.spec

  • added tests to help me debug integration test problems.

stateRenderer-v2.js can still use some serious clean up.

📋 Tasks

Make sure you

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

[knsv]

Great feature @weedySeaDragon! I particularly like that you aligned the syntax with flowcharts. One of the issues we need to be aware of the keeping the syntax together between the diagrams to simplify for the users! If you rebase I will merge!

[weedySeaDragon]

Thanks @knsv . Yes -- users should expect the same experience and abilities across the different diagrams. (They don't know that the code is so different for them.)
Obviously the more we can refactor to use common code, the easier it will be to achieve it. :-)

I'll work on the documentation for this feature next.