TinyMCE Single with React

[anna-harrison]

In addition to the TinyMCE-per-block (prototype 2) vs TinyMCE-single (prototype 3) tradeoffs, another significant difference is the use of React (prototype 2) vs direct DOM manipulation (prototype 3) for the UI

Implement a branch of TinyMCE-single (prototype 3) using React
Include alternate UI from #215

This will let us compare

1. TinyMCE-per-block + React vs. TinyMCE-single + React
2. Direct DOM UI vs. React UI

[intronic]

I definitely found it quicker and easier to prototype different alternative UI options using React.

[prototypo]

This seems like the best of both worlds: React plus a single TinyMCE.

[prototypo]

Anna has added a video of the (still nascent) prototype in action in #215

[jasmussen]

CC: @dmsnell because I know he's voiced some thoughts on using React in WordPress.

Anna has added a video of the (still nascent) prototype in action in #215

@prototypo Where does this prototype live?

In order to minimize duplicate work it would be nice for development of any prototypes to happen in the open, especially as currently we are planning only two technical prototypes that are already underway, both adhering to the UI baseline. In general, prototyping work in this phase should ideally either be part of those two technical prototypes, or be separate UI-only prototypes (GIFs, mockups, fiddles, Marvel click-through's) to explore various solutions to tickets labelled Design.

[dmsnell]

voiced some thoughts on using React in WordPress

some muddled concerns that probably aren't that big a deal at this point. if we wrap something in React we could likely just as easily wrap it in a Web Component or some other completely free system that certain businesses and organizations wouldn't shy away from

[intronic]

I take the point about React. In the above description;

s/React/some-virtual-dom-based-declarative-model/g

And the argument stands. React is already being used in prototype 2 so we thought to try it to compare & contrast vs the direct-mutation model, given the prototype nature.

There are other completely free alternatives to React that are along the same lines, some even fairy drop-in replacements at the api level, if that general path were chosen.

[intronic]

Hi @jasmussen,

It is in the open, but just not easily discoverable for some reason. It seems our accounts maybe aren't associated with the project or something; we dont come up in at-mentions for instance.

Maurizio (mimo84) & I (intronic) forked from the Ephox gutenberg fork (just a few days ago) since at this stage we are still learning the gutenberg code & goals. (we are using the latest master from this repo, though).

Its very exploratory right now as we are figuring out how the two prototypes are being put together. Once we have something concrete sorted we'll set up a PR. Its just that we're not there yet.

Cheers,
M

[prototypo]

@jasmussen The prototype is being worked in a fork of gutenberg at https://github.com/ephox/gutenberg. But @intronic is right about org permissions; we'll have a look at that on Monday our time. Sorry for the trouble.

Please expect a PR soonest, probably early next week.

[jasmussen]

@intronic @prototypo I wasn't aware you didn't already have commit access or other privileges here, we can get those for you easily. You should've just asked.

[intronic]

@jasmussen @prototypo - on my part, honestly, my first goal was to get my head around all the moving parts in gutenberg.

There are a lot of parts, moving very fast. We'll catch up & integrate ourselves v. soon :)

[aduth]

And the argument stands. React is already being used in prototype 2 so we thought to try it to compare & contrast vs the direct-mutation model, given the prototype nature.

Not that it makes much difference to the discussion, but worth clarifying that it's an abstraction of React (had even previously not used react proper), for the point of considering whether it makes sense to have flexibility in swapping the underlying implementation; for example, perhaps one of the hyperscript sort which is mostly compatible in its APIs but not virtualized.

[jasmussen]

Merged in the prototype. Let's take the learnings we got from that prototype and either keep them in mind as we work on existing tickets, or open new ones if there were particularly valuable take-aways not yet ticketed.