It would be nice to be able to write markdown syntax inside Vue components located in markdown files. That would allow for markdown-centric UI components:
<!-- readme.md -->
<Accordion>
<AccordionItem label="One">
This is the *first* section.
</AccordionItem>
<AccordionItem label="Two">
This is the *second* section.
</AccordionItem>
<AccordionItem label="Three">
This is the *third* section.
</AccordionItem>
</Accordion>
While I could parse these slots inside the AccordionItem, that would unfortunately not benefit from SSR. So it would be cool having some way to enable the markdown renderer inside component slots. I'm not sure what a good API would look like, but I could imagine a special attribute, for example <AccordionItem vp-markdown />.
Such a component could be designed even more content-centric:
<Accordion vp-markdown>
* One
This is the *first* section.
* Two
This is the *second* section.
* Three
This is the *third* section.
</Accordion>
That's obviously not the greatest use of Vue components (since it could easily be implemented in plain JavaScript), but it's nice & clean markdown for content authors and would produce readable markup in the SSR.
Thanks! But it should be worked. You just missed two blank lines:
<Accordion vp-markdown>
* One
This is the *first* section.
* Two
This is the *second* section.
* Three
This is the *third* section.
</Accordion>
Oh dear, I didn't realize that. Thanks for pointing it out!
Can I ask why are those blank lines required?
I wanted to create custom component that would replace custom blocks, because that custom block syntax ::: doesn't play well with prettier.
Is there any way to circumvent this? So I could write
<Tip>
Content with **markdown** support
</Tip>
instead of
<Tip>
Content with **markdown** support
</Tip>
with my component?
I don't think there's a way to do that unless you're going to change the parser directly.
This behaviour is provided by markdown-it, the markdown parser VuePress uses.
I just took a slightly deeper look into this:
markdown-it parses the code this way because it strictly follows the CommonMark spec. This spec has a dedicated section about HTML blocks which specifies exactly the behaviour we're observing here.
The spec is written by some really clever folks, so you can rest assured that there has been put some thought in the way HTML blocks are specified. I haven't read the spec thoroughly so I'm not sure if it contains written reasoning for that specific design decision, but feel free to dig into it.
Thanks for the info. I'll just keep the blank lines, it's not a deal breaker for me.
Most helpful comment
Thanks! But it should be worked. You just missed two blank lines: