Add support to render and edit FrontMatter

[susnux]

• Resolves: Support Frontmatter in MD files #145
• Target version: master

Summary

This adds support to show and edit a FrontMatter block as a simple code block.

This does not introduce special parsing and rendering like suggested here: #145 (comment)
Because that requires to assume a language, while mostly YAML is used, I already saw a lot projects using TOML or even JSON in the FrontMatter. So using a simple code block allows us to not make any farfetched assumptions about the content while still gives the user a convenient way to edit.

I only added a hr element to visually separate FrontMatter from content.

You can even remove the FrontMatter if you like, and copy it, pasted FrontMatter will result in a simple code block as the FrontMatter is only allowed as the first element of a document.

What is not implemented: Adding a new FrontMatter to a document, while implementing this would be straightforward it would add more UI elements and so I would like to have some feedback if I should add such functionality / interface elements.

---

Example

Sourcecode

---
some: value
other: 2.3
---
# Heading
```
Code block
```

After / With this PR

Before / Without this PR

[max-nextcloud]

This is great! I think it covers the main use case of being able to handle markdown files with front matter without adding much complexity. I'd personally stick to not exposing the front matter functionality in the ui - but if someone has a clever idea of how to handle this i'm all ears.

Two questions come to my mind:

• What happens with front matter that is affected by the escape html? It would be nice if it would be preserved when opening the file in text. Maybe we could even add a test for this.
• What happens if the front matter block is copied and pasted further down in the document? Does it add a frontmatter node?

The latter question makes me think it might be good to just define a new node type instead of inheriting code block. This would avoid inheriting the input rules, keyboard shortcuts and all that. The new node type could also not be part of the 'block' group and would then not be allowed in the document. Instead we could prefix the document content with a frontmatter? expression so front matter can only occur at the start of the document and only once.

[juliusknorr]

Very nice :) I agree that we should probably think about how if and how we actually present this to the user.

• Maybe we can collapse it by default and explicitly add a front matter label, however that is quite technical
  • On the other hand we would only expose this is someone already has frontmatter in their document
• It could be separated visually a bit more to not look exactly like a code block, maybe a lighter background

Maybe @nimishavijay or @jancborchardt also have some input on this.

[jancborchardt]

It seems reasonable to show it like a code block indeed. If Frontmatter is used, then it's likely understood and can be shown directly?

We can still do any improvements if issues come up, but don't need to overengineer at this stage. :)

[susnux]

Thank you for your feedback!

• What happens with front matter that is affected by the escape html

Not much as it is reverted when serialized to markdown, it only sanitizes for the HTML output. (see below)

• What happens if the front matter block is copied and pasted further down in the document?

The pasted one is transformed to a normal code block. (see below)

I'd personally stick to not exposing the front matter functionality in the ui - but if someone has a clever idea of how to handle this i'm all ears

I have some local changes which would introduce an input rule:
If you enter three dashes at the beginning of the document they would transform into a front matter node instead of a hr.
Does this solution sound reasonable to include?

It could be separated visually a bit more to not look exactly like a code block

Maybe this way? This are my local changes including slightly different styling and the input rule.

front-matter.mp4

[juliusknorr]

I'd personally stick to not exposing the front matter functionality in the ui - but if someone has a clever idea of how to handle this i'm all ears

I have some local changes which would introduce an input rule: If you enter three dashes at the beginning of the document they would transform into a front matter node instead of a hr. Does this solution sound reasonable to include?

Yes, I think that is a nice feature to be able to add it even if we don't expose a button.

It could be separated visually a bit more to not look exactly like a code block

Maybe this way? This are my local changes including slightly different styling and the input rule.

Looks nice 👍

[max-nextcloud]

Thanks for overwriting the tiptap code block rules to make sure they don't apply later in the doc.

I think this is ready to go! 🚀

[juliusknorr]

Tested and works like a charm, apart from the small comment about the "Front matter" label this is good to go from my side, so LGTM after that is addressed.

[susnux]

Added some test, unfortunately cypress does not support copy paste (somewhat related to cypress-io/cypress#2386 ).
Also fixed serializing of a front matter containing a sequence of three or more dashes, this is valid but the fences must be longer than the sequence within the content.

[susnux]

/compile

[juliusknorr]

Awesome contribution @susnux Thanks a lot for that :)

[juliusknorr]

Ah failure seems related to the recent server login page change ... waiting for #2756 then for the merge.

[susnux]

/compile

[jancborchardt]

Looks great now, nice work @susnux! :)

The blue line on the bottom we could instead do on the left like for the infoboxes – but that is not blocking and can be done in a follow-up.

[susnux]

Looks great now, nice work @susnux! :)

Thank you!

The blue line on the bottom we could instead do on the left like for the infoboxes – but that is not blocking and can be done in a follow-up.

I did this on purpose, to create some (visual) vertical separation (front matter vs file content).
But I am fine with changing it to match the infobox design, I have attached screenshots of both designs, so @jancborchardt if you like the second one more I will change it :)

Currently

Proposed one

[jancborchardt]

Very cool @susnux! The proposed one (with just the blue bar on the left, no icon) is definitely the best. :) And it still looks consistent with the rest.

[susnux]

/compile amend

[susnux]

The proposed one (with just the blue bar on the left, no icon) is definitely the best. :) And it still looks consistent with the rest.

Ok changed the design accordingly :)

[susnux]

/compile amend