DOM / Text Renderer removal (copy / paste implications)
Opened this issue · 0 comments
Summary
Currently we ship DOMRenderer and TextRenderer with MobiledocKit by default. In a previous PR I mentioned we could deprecate a small section of code (see details here) and reduce the overall package size. However, upon closer inspect I found that these Renderers are necessary for copy/paste fidelity.
Essentially the Copy Past flow is as follows:
- Select range of text (including atoms/cards et, al)
- Copy it with system hot-key
setClipboardData
function is called which is responsible for:- Setting the
{html, text}
representation on theevent.clipboardData
object - It does so by receiving the
mobiledoc
object, thehtml
from the result of DOMRenderer render, andtext
from the result of TextREnderer call html
is encoded (by mime type) like so:html = ``<div data-mobiledoc='${JSON.stringify(mobiledoc)}'>${html}</div>``;
text
is encoded (by mime type) by simply setting it
- Setting the
- Paste range of text with system hot-key
parsePostFromPaste
function is called which is responsible for returning amobiledoc
post
from html if specified and constructing one from text
This allows copy/paste to parse the mobiledoc
document to preserve fidelity when pasting between different mobiledoc editors and within itself and still allows text copy/paste to work as you'd expect wrt system pastes.
The Problem
- In order for us to have this fidelity we need to include the DOM/TextRenderers which bloats the payload and may not be necessary.
- It means that the current copy/paste functionality cannot be overridden or configured.
- Implication here is that custom renderers would not be factored in to the copy/paste solution since they are hardcoded to be the standalone packages.
Design
Remove default copy/paste solution. Which would mean that the default system copy would be what happens and we'd lose fidelity of cards et, al.
Provide an easy configuration to allow a DOMRenderer that if specified would be utilized in the copy/paste flow listed above.
Drawbacks
- This represents a breaking change
- This would necessitate us updating documentation to show various examples of how to specify this behavior
Alternatives
Leave default implementation in place, but allow override of DOMRenderer. Though this would still involve shipping the DOMRenderer with MDK