Improving deserialization

[dylans]

In general you can paste data into a slate editor today as text/html, application/x-slate-fragment, or text/plain (there are of course other mime types, which I'll get to at the end, but these are the ones we handle today).

• Currently we have 2 deserializers, HTML and markdown. In general you need to decide between HTML or markdown, though perhaps we could be more clever.
• Pasting within a slate document requires writing a perfect deserializer for the slate tree (iiuc), whereas it is often more convenient to handle the paste as application/x-slate-fragment.
• Our current HTML deserializer does some nice things to clean up what gets pasted from slate, namely the issue of losing formatting of the first element in the paste buffer.

For me, paste from HTML is better when copying content from other websites rather than from within slate documents. This is due to deserializers being difficult to write for more complex custom plugins.

I would propose we make deserialization an order of magnitude easier to use and more flexible with the following suggestions:

• Regardless of what deserializer is active, if the paste buffer contains application/x-slate-fragment, have a way to rely on this first (perhaps a configurable order of paste preference?).

• Apply similar logic if possible from createDeserializeHTMLPlugin to handle pasting an application/x-slate-fragment (perhaps this becomes a createDeserializeSlatePlugin or something similar? to clean up known slate issues when pasting slate content into a slate document)

• If using a default paste preference order, if application/x-slate-fragment is empty, then handle paste as html, assuming that text/html is non-empty

• If both application/x-slate-fragment and text/html are empty, handle as plain text. With plain text, if the createDeserializeMarkdownPlugin is enabled, paste the parsing as if it was markdown

• In the future, consider other paste deserializers, the most obvious one being paste from word, but also perhaps csv to insert a table, etc.

Implementing this change is probably beyond my current capabilities, but I'm happy to help if you think it's useful and if I'm not missing something obvious that would break or simply doesn't work with my thinking.

[zbeyens]

All good.

The easiest would be a single mixed deserializer but this removes our decoupling value.

We can create createDeserializePlugin which would contain rules option mapping to any deserializer: e.g. Slate > HTML > Markdown > Text

[dylans]

Step 1: createDeserializeAstPlugin: #785

[xypnox]

Also, as an addition to the last step of determining how to handle the pasted content, we need to also handle the case of the pasted plaintext being a link. If so, when it is pasted, it should be converted to link, or when pasted over a selection, the selection should be "link-ified".

This does not happen when another deserializer is used (eg. Markdown).

More details: #800

[dylans]

Current state: This now works quite nicely with Slate Ast, HTML, and Markdown.

Usage looks something like this (the deserializer that you want to get called first gets included last in your list of plugins (for the latter I've added an example of calling one of the overrides, but this should not be necessary for most use cases):

      p.push(createDeserializeCsvPlugin({ plugins: p }));
      p.push(createDeserializeHTMLPlugin({ plugins: p }));
      p.push(
        createDeserializeAstPlugin({
          plugins: p,
          getFragment: fragment => {
            return fragment[0].children;
          },
        }),
      );

I also have a CSV deserializer that works. Parsing CSV is heavily dependent on the CSV parser of choice. For now I've chosen one (PapaParse) that seems to meet most CSV parsing needs (relatively small, works in all environments, handles several different CSV formats, has a decent number of configuration options, is actively maintained). I'll raise a PR soon for that.