Use raw format when setting Editable content

[aduth]

Related: #635

This is a continuation of #635, applying a commit that had been removed there to use raw formatting when setting content to the TinyMCE instance. It was removed due to the behavior of the Text -> Heading transform creating content with an invalid structure that had relied on TinyMCE's content sanitization.

For example, what would have previously been transformed as <h2>foo<p>bar</p></h2> should now be correctly transformed as <h2>foobar</h2>.

Implementation notes:

I don't like that I chose to call to .props.children in assigning the heading content. In fact, I think if at all possible, we should avoid having block implementers work with or manipulate these element trees at all. I think this can be improved by structuring the Text block's content attribute as an array. I recall we'd explored this at one point but found it "easy" to treat the text content as a single element blob. I suspect this will be an tempting escape for many blocks, so we should consider how best to encourage meaningful data structures for blocks, because doing so will help facilitate manipulating those structures (such as in transforming or merging blocks).

I'll plan to explore these ideas further in a subsequent pull request.

Testing instructions:

Verify that there are no regressions in merging a paragraph block into a heading block, including if the text block includes multiple paragraphs (should only merge the first of the paragraphs into the heading and preserve the rest).

1. Add a Heading block
2. Insert some text into the new Heading block
3. Add a Text block
4. Insert multiple paragraphs of text into the new Text block
5. Put cursor focus at beginning of text block
6. Press backspace
7. Note that the first of the Text block's paragraphs is appended to the Heading content

[ellatrix]

It may be easier once we move inline elements into a single string with paths where they start and and. When it happens that there are block elements in this content, we could flatten the text content. I guess this is for a bit in the future though.

[youknowriad]

Can you explain what are the benefits of raw content? I think performance, but I don't expect this setContent to be run a lot of times.

I guess my concern is. Are we really "ok" to skip the TinyMCE validation? What if we decide to add some content filtering https://www.tinymce.com/docs/configure/content-filtering/#valid_elements I'd prefer if we let TinyMCE perform this task for our selves.

[ellatrix]

Re performance: I don't have a scenario in mind where we would be setting a lot.

[aduth]

Are we really "ok" to skip the TinyMCE validation?

Yes, I think we should be fine with this. We shouldn't allow invalid content to enter the editor state in the first place. In fact, thinking on this some more, I found an obvious issue on master:

1. Insert Heading block with some content
2. Insert Text block with some content
3. Merge Text block into Heading block
4. Switch to Text mode
5. Observe serialized Heading block includes undesired <p> tag

The current behavior is really only giving us the illusion that it's helping in the context of the visual editor. We shouldn't need to leverage TinyMCE to ensure that we cleanly merge two blocks.

[youknowriad]

I can be convinced, but this adds a lot of things for us to do. Not only when merging but also when parsing. We should provide helpers maybe to do this filtering, because it can be a difficult task to do and we should leverage this in a unified way.

[aduth]

What specific things are you thinking that this will leave for us to do? And in what ways does TinyMCE's sanitization help with this that doesn't just display nicely in the editor, but also fixes the underlying broken content?

[youknowriad]

I think each time we use an Editable we'd want to provide valid_elements to say which tags, attributes etc... this Editable allows (We'll need good defaults). if we use TinyMCE's valid_elements setting for this, there's not much left for us to do.

But I can be convinced that the content should have already been sanitised in the block attributes and I'm thinking, we could offer a helper to do this sanitization outside of TinyMCE.

[aduth]

Yeah, I can see how we might want some sort of element validation, but I don't think it'll be in the direction of...

1. Try setting invalid HTML to Editable
2. TinyMCE cleans it up
3. TinyMCE passes back clean HTML to us

...but rather more like...

1. Editor state is always valid
2. User manages to enter invalid markup into Editable
3. It's cleaned up when markup is converted back into an element before being updated in state (related, Try avoiding parse to get content of Editable #523)