Add Kroki support

[op8867555]

Hi,
This patch is my attempt to support Kroki diagram(and fixes #4242).
It is basically a clone of Mermaid Node with some modifications.

• isDark removed since Kroki doesn't support it.
• kroki_${DIAGRAM} are used to choose different Kroki diagrams.
• I haven't figure out how to pass a Integration url to a Node, so url of the Kroki instance is hard-coded to https://kroki.io now.
• Mermaid.js is also supported by Kroki too, so it might able to replace current mermaid.js implementation.
• I guess I could also remove the Cache since it not so meaningful in the case.

P.S. I'm not so familiar with TypeScript/React, just hoping this could make some progress to having Kroki support in Outline. Please feel free to give this a try.

[CLAassistant]

All committers have signed the CLA.

[tommoor]

Hi, this is very interesting – thanks for the contribution. I have a couple of concerns, I'm sure they may be alleviated though…

• Kroki involves sending your data to a third party service to render it, this is by necessity going to be slower than rendering in the client and also is a data privacy issue. I'm not sure how to communicate this to users effectively 🤔 . Relying on a third party service to render key parts of a document seems kind of anti-Outline in some ways.
• Having so many different niche diagram types seems overwhelming, I've never heard of most of these and mixing diagrams with code languages isn't ideal so I think this part of the interface would need some thought to.

[op8867555]

• Kroki involves sending your data to a third party service to render it, this is by necessity going to be slower than rendering in the client and also is a data privacy issue. I'm not sure how to communicate this to users effectively 🤔 .
  Relying on a third party service to render key parts of a document seems kind of anti-Outline in some ways.

Since we can self-host Korki, I'm personally fine with running an extra service for this, it can just acts as another dependency like redis/MySQL. On the side of rendering speed, already-created diagrams will be cached by browser, though it will be slower when editing the diagram, I think it's a acceptable trade-off.

I don't have strong opinion on replacing mermaid.js by kroki, just thinking this might make upgrading mermaid.js more easily. Also IMO mermaid.js is already a third party component, so I guess the real difference is switching from client-side to server-side rendering.

• Having so many different niche diagram types seems overwhelming, I've never heard of most of these and mixing diagrams with code languages isn't ideal so I think this part of the interface would need some thought to.

That is true. I don't use diagrams other than plantuml so much. I think one possible design is merge all Kroki diagrams as a single language, than add some custom instruction/syntax to choose the specific diagram, for example:

```kroki
type plantuml;
...
```

Or maybe making a new variant of CodeBlock for Kroki with a separate language list for diagram types?

[op8867555]

Having so many different niche diagram types seems overwhelming, I've never heard of most of these and mixing diagrams with code languages isn't ideal so I think this part of the interface would need some thought to.

I just made some UI changes to improve this one:

• code and Kroki diagram languages are separated now, no more diagram languages in a code block
• Only / command or + button can create a Kroki Diagram block
  

[tommoor]

Thanks – this is a reasonable solution that I'm onboard with, unfortunately it does make this PR another one that's dependent on #3000 as the diagram attribute is not serialized into the Markdown itself the diagram will not be properly displayed on first render or on publicly shared documents – two places where we still rely on rendering directly from the Markdown itself.

[op8867555]

ok, I guess I can just remove the use of diagram by using language instead, is that a preferable solution for now?

[tommoor]

I don't think it's preferable, it is best to have this dependent on #3000 which is top of the roadmap to complete right now, so should be done soon

[op8867555]

Got it, it seems there isn't much I can do until #3000 get done. Thanks for your time & considering this approach :)