[Tracking Issue] Implement HTML -> Markdown conversions in Expensimark

[roryabraham]

Problem

Expensify.cash uses the Expensimark library in the expensify-common repo to convert markdown to HTML. That way, a user can compose a message using markdown, and it can be displayed + stored using HTML. However, when a user later goes to edit the message, we currently have no way to take the HTML and display it to them as markdown. We also don't want to store the original markdown in our database.

Why this is important

Editing comments is an important usability feature in Expensify.cash. However, we need to make sure that the edit-comment experience is as similar as possible to the original message composition experience.

Solution

Implement bi-directional HTML <---> Markdown conversion in Expensimark for all of the elements we currently support for Markdown ---> HTML conversion:

• Code fence - Implement Code Fence HTML to markdown conversion [Hold for payment on August 13th] #4184
• Inline code blocks - [Hold for payment 2020-08-09] Implement Inline Code Block HTML to markdown conversion #4185
• Email links - [Hold for Payment 13 August] Implement Hyperlink and Email link HTML to markdown conversion #4187
• Hyperlinks - [Hold for Payment 13 August] Implement Hyperlink and Email link HTML to markdown conversion #4187
• Bold
• Italics
• Strikethrough
• BlockQuotes - Implement Block quote HTML to markdown conversion #4188
• Newline / <br /> - [HOLD for payment July 22] Update line break regex for HTML->Markdown to support break tags with styles #4052
• Special characters (& currently looks like &amp when you go to edit a previously sent message with & in it) - [HOLD for payment August 4) Fix message Editing and pasting issues. #4169

[roryabraham]

HOLDing this on a POC PR over here. We might need to do an internal PR to update our other repos that also use Expensimark, depending on how we change the Expensimark interface.

[jasperhuangg]

@roryabraham I was just thinking about this–and sorry if this has already been considered–but why don't we just store both the HTML and markdown versions of the report comment, and switch between the two for editing/copying report comments?

To minimize space, we can only store the HTML if the markdown and the HTML are identical (and default to it if the markdown version doesn't exist).

Feel like this would be a whole lot simpler than doing a bunch of string manipulation on HTML to make it look like markdown–we'd probably also avoid a bunch of bugs this way.

[parasharrajat]

@jasperhuangg has raised a very good point. But I think it in another way. I would say that we should save the MD as I believe converting HTML to markdown will loose original MD markup which user entered.

And we can always convert the MD to HTML uniformly.

[roryabraham]

I don't necessarily disagree @jasperhuangg, but this was discussed in slack here. If you'd like to reopen the discussion, I think Slack would be the best place for that so it gets better visibility. The reason we didn't go with that solution is that it will nearly double the amount of data we need to store in our largest table.

But @parasharrajat has introduced an interesting solution I don't believe was discussed before – only store the plain-text (markdown) version of a comment, then convert it to HTML only when needed.

[roryabraham]

Raised the proposal to store only markdown in this slack thread.

[roryabraham]

Moving forward with the original plan, I'm taking this off hold.

[roryabraham]

For reference, this PR was merged as a POC, and it's being integrated into E.cash here.