Compare the different technical approaches

[youknowriad]

So far, we have these technical prototypes:

1- https://wordpress.github.io/gutenberg/tinymce-per-block/

• Multi-TinyMCE
• Controlled ( state -> render -> event -> state -> rerender )
• The state is represented as an Object
• Using Grammar

2- https://wordpress.github.io/gutenberg/tinymce-single/ (Single TinyMCE, uncontrolled, no grammar, HTML parsing)

• Single Global TinyMCE
• Uncontrolled ( state -> render -> event -> newState )
• The state is a simple string containing the whole HTML
• Not using the Grammar inside the editor but we may be able to add the grammar comments while calling tinymce.getContent

(Feel free to add any other technical prototype here)

I'm creating this issue so we can compare the pros/cons of each approach to help us decide which approach we choose to implement.

[youknowriad]

Here are my feelings about these two prototypes:

Prototype 1:

Pros:

• Seems easier to use Blocks outside the editor context
• I have a personal preference over having the state as an Object, external manipulation of the state (actions not built-in in TinyMCE) seem easier to achieve.

Cons:

• Multi-block selection seems impossible to achieve. Ctrl+A is per block.

Prototype 2:

Pros:

• Multi-block selection
• Easier to achieve a Full-text UI feeling

Cons

• Harder to reuse the blocks outside the editor?
• TinyMCE can override some of the default behaviour inside block content https://wordpress.slack.com/archives/core-tinymce/p1487169326000067

Based on this experimental prototype #113 I tried to work on a mixed approach where we use TinyMCE as a wrapper but rerender its content based on state changes. After some exploration, this approach feels like trying to recreate DraftJS or ProseMirror. And I don't think it's the right way to use TinyMCE.

[jasmussen]

Thanks for creating this ticket.

As we compare we should also think of #3, as that seems dependant on which approach we choose.

[BE-Webdesign]

I think Prototype 2 is the way to go, although it might be more of a pain because it will involve a lot more TinyMCE work, ultimately it would probably be the best approach forward for now.

Harder to reuse the blocks outside the editor?

I think that would not be a con for Prototype 2, as long as the API for defining Block Types and Control types provides enough data for something other than TinyMCE to use. I think we should develop an Block Type/Control Type defining API that will be used to feed a highly Custom TinyMCE instance. Data from the Block Type/Control Type could also be used to feed something else potentially in the future.

As much as it is probably not palatable, Prototype 2 mirrors the most of how WordPress already works and TinyMCE does a lot, which to me makes it a very sensible path forward.