Gutenberg: Compare the different technical approaches

Created on 23 Feb 2017 · 3Comments · Source: WordPress/gutenberg

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.

[Type] Question

Source

youknowriad

Most helpful comment

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 https://github.com/WordPress/gutenberg/pull/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.

youknowriad on 23 Feb 2017

❤3

All 3 comments

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

youknowriad on 23 Feb 2017

❤3

Thanks for creating this ticket.

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

jasmussen on 23 Feb 2017

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.