Feature Request: Gracefully Degrade Non-Standard Markdown

I have a lot of retype documents that I need to convert to standard markdown. I have used components when writing those documents but that now means that I have to go through them all and strip out those components, this causes me a lot of extra work.

It would be better if features that are unique to retype and require retype for proper rendering would gracefully degrade when converted with any other export tool such as pandoc. I don't know exactly how to accomplish this but perhaps something like using comments for specifying the component directives: My Tab

The end result should be that if retype is used you get the expected result that retype would generate, however, if any other conversion tool were used you could still produce clean standard HTML as though the retype components were not present.

Removing the Retype Flavored Markdown component syntax across an entire project is super easy by using search-and-replace, especially a Regular Expression search-and-replace.

By just using the following three patterns on the retype.com project, I was able to strip basically everything out in just a few seconds total.

Component	Search	Replace
Block component start	`^(===\\|==-\\|\+\+\+\\|!!!\\|\\|\\|\\|) (.*)\n`	`### $1\n\n`
Block component end	`^(===\\|==-\\|\+\+\+\\|!!!\\|\\|\\|\\|)`	empty
Inline component	`\[!(badge\\|button\\|file\\|embed\\|ref)\s`	`[`

There are a few edge cases that the above patterns did not capture, but just adjusting the patterns slightly would capture all those too.

You can enable regex search in most text or code editors by looking for the following buttons:

In Visual Studio Code:

In Sublime:

I would also argue that Retype Flavored Markdown does degrade gracefully into pure Markdown. That is one of the primary advantages of Retype compared to all other generators, and that you not locked into a tangled mess of inline code (non-markdown) that are required of other generators.

For instance, let's compare the Tab component syntax generated by GitBook:

{% tabs %}
{% tab title="Apple" %}
This is an apple 🍎
{% endtab %}

{% tab title="Orange" %}
This is an orange 🍊
{% endtab %}

{% tab title="Banana" %}
This is a banana 🍌
{% endtab %}
{% endtabs %}

And here's what the above GitBook Tabs looks like rendered in HTML:

{% tabs %} {% tab title="Apple" %} This is an apple 🍎 {% endtab %}

{% tab title="Orange" %} This is an orange 🍊 {% endtab %}

{% tab title="Banana" %} This is a banana 🍌 {% endtab %} {% endtabs %}

Here are the same Tabs in Docusaurus:

<Tabs>
  <TabItem value="apple" label="Apple" default>
    This is an apple 🍎
  </TabItem>
  <TabItem value="orange" label="Orange">
    This is an orange 🍊
  </TabItem>
  <TabItem value="banana" label="Banana">
    This is a banana 🍌
  </TabItem>
</Tabs>

And here's what the above Docusaurus Tabs looks like rendered in HTML:

This is an apple 🍎 This is an orange 🍊 This is a banana 🍌

Every other similar generator has some kind of leaky abstraction on the above, most being even more convoluted and platform specific than the next.

Here are the same Tabs in Retype Markdown:

+++ Apple
This is an apple 🍎
+++ Orange
This is an orange 🍊
+++ Banana
This is a banana 🍌
+++

And here's what the above looks like rendered in HTML:

+++ Apple This is an apple 🍎 +++ Orange This is an orange 🍊 +++ Banana This is a banana 🍌 +++

Converting the GitBook and Docusaurus Tab syntax into clean readable Markdown is a tedious task, certainly when compared to Retype.

Hope this helps.

retypeapp / retype

Feature Request: Gracefully Degrade Non-Standard Markdown #524