Experimental: Remove children matcher in favor of HTML

[aduth]

Related: #421, #466

The children matcher was introduced in #466 as a solution to the issue where serializing content as a React element in the save implementation would require the block implementer to use dangerouslySetInnerHTML, which was unnatural (and scare-inducing) compared to typical React children rendering. The result of save is only ever used to generate the string content to be saved in post content, so escaping the rich HTML of an Editable field value is undesirable.

This pull request seeks to explore an alternative solution, preferring to manage the Editable (TinyMCE) value as a string, and overcoming the issue of dangerouslySetInnerHTML by intercepting and traversing the return value of save to replace a string children prop with the equivalent dangerouslySetInnerHTML. The magic occurs in serializer.js:

content = traverse( content, {
	DOMElement( { node, traverseChildren } ) {
		if ( 'string' === typeof node.props.children ) {
			return cloneElement( node, {
				...node.props,
				dangerouslySetInnerHTML: {
					__html: node.props.children,
				},
				children: undefined,
			} );
		}

		return cloneElement( node, node.props, ...traverseChildren() );
	},
} );

See also: https://github.com/elierotenberg/react-traverse

This has a few benefits:

• Fewer matchers to have knowledge of
• Avoids nodeListToReact / renderToString dance in Editable (more performant)
• Editable change detection is a simple reference comparison (more performant and accurate than deep isEqual on element trees)
• Eliminates concatChildren because concatenating values is a simple addition operator with strings

This is a work-in-progress, notably:

• Transforms need to be updated to treat children content as string
• Security audit; I'd like to see if we could at least avoid the dangerouslySetInnerHTML in the TinyMCE component and instead set content via traditional TinyMCE setContent (with sanitization)

[aduth]

I'm going to close this as not worth pursuing. Managing content as strings solves some problems, particularly around storing elements in state and serializing them (e.g. websockets), but at the cost of flexibility of understanding, slicing, mapping the true shape of the content.