## Problem
When we stores a Note's content right now we store the plain HTML to our DB, while it's a very simple and straight forward approach that can work in many simpler cases, it has the problem of coupling the actual data representation to a specific strict rendering markup, in this case is HTML.

This becomes especially troublesome once the editor's features become more complex (e.g. Zettelkasten) or when the editor has different implementations (e.g a mobile app).

## Solution

The overall solution I propose is to sanitize the editor's markup output to a data structure that represnts the the Note's description before persising it. This can be achieved in a couple of ways.

To be clear, what I mean by that is, instead of saving the Note's content as:

<p> Some content </p>
<ol>
<li> Item 1 </li>
<li> Item 2 </li>
</ol>
<div>
    <div class="image-toolbar">
        <div id="align-left-button"/>
        <div id="full-size-button"/>
        <div id="delete-button"/>
    </div>
    <img style="width: 50%; float: left;"  src="cloudnary.mindvalleu/image1.png"/>
</div>

We would save as something ddd like:

[{
 "type": "text-block",
 "content": "Some content"
}, 
{
 "type": "orded-list",
 "content": ["Item 1", "Item 2"] 
},
{
"type": "image",
"content": "cloudnary.mindvalleu/image1.png",
"aligment": "left"
}]

This way the editor who's rendering have all the iformation of how the render each section, and can 1) perform operations such as inejecting the "image-toolbar" while parsing the data strcutre and 2) parse to whichever markup is more suitable for that particular editor (HTML for web and whatever mobile uses for mobile).

This unlocks a lot of power of customization to our editor.

Also, also worth nothing that the HTML I used as an example was a simplification, the real thing is much messier :see_no_evil:

Now, there are a couple ways we can achieve this

### 1) Come up with our own thing

In this option we'll come up with our own data structure to represent our Note's blocks and implement our own sanitizer/parser.
The first step is to to carefully look throught the possible styling and features we have in our editor and come up with the data structure we'll use to represent it, similar to what I started in the exemple above. Then we write a **sanitizer** and a **parser** in order to transform the HTML to the data strucutre and vice verse. Then migrate the content of all of our Notes to the specified format using the sanitizer.

I used [Slack Block Kit](https://api.slack.com/block-kit) as inspiration for my previous example, probably is a good starting point.

#### Pros
- We get to keep the same editor
- Probably easier/less work (not sure though)

#### Cons
- Coming up with the data structure will be tricky, especially when you consider block sections with mutiple styles in the same block (e.g links, bold, itallic).
- We'll have to implement one sanitizer/parser for each markup lang we'll support.
- Note sure how much of an advantage is to keep the editor we use right now as it [looks like it's dying](https://github.com/yabwe/medium-editor/issues/1547) (last commit is 12months ago)

### 2) Use QuillJs

[QuillJs](https://quilljs.com/) is another editor that's super powerful and costumizable, it's [huge on github](https://github.com/quilljs/quill) with more then 30K stars (so a lot of support and tooling) and it's actually the editor that powers Medium, so good benchmark. It has a lot features, but the key ones for us is 1) this [Delta parser](https://quilljs.com/docs/delta/) that gives the whole preivous solution for us out of the box and 2) [Parchment](https://quilljs.com/guides/how-to-customize-quill/#content-and-formatting) a document-model abstraction that allow us to build pretty much any editing feature on the editor.

Chosing this solution means rewriting the whole editor FE, then using the power of the Delta parser to store our content int he DB. We'd also have to come up with a way to migrate all the data to this new format using the Data parser.

#### Pros

- Whole parsing/sanitizing solution working out of the box with a well stablished and widly used format.
- Gives the chance to reimplement the editor.
- Possibily making it neater.
- Allowing easier implementation of complex features such as Zettelkasten.
- They even have a [medium editor clone tutorial](https://quilljs.com/guides/cloning-medium-with-parchment/) we can user as starting point.
- Has a bunch of [satellite projects](https://github.com/quilljs/awesome-quill) to support us in the future (Even some parsers to native mobile).
- It's used by Medium, Slack and other big players so looks very poweful and stable.

#### Cons

- We'll have to rebuild the editor from scratch
- Probably will take more time
- Note's data migration will be a bit tricky, might need to use some Node script to do it

As a final note, no matter which options we choose, we should probably save the Note's description as plain-text as well. Right now we're doing it on read but I don't see why not doing it on write. This will also enable full text search, being trhough Aloglia or other solution.