到目前为止，我们有这些技术原型：
1- https://wordpress.github.io/gutenberg/tinymce-per-block/
- 多微型MCE
- 受控（状态 -> 渲染 -> 事件 -> 状态 -> 重新渲染）
- 状态表示为一个对象
- 使用语法
2- https://wordpress.github.io/gutenberg/tinymce-single/ （单个TinyMCE，不受控制，无语法，HTML解析）
- 单个全局 TinyMCE
- 不受控制（状态 -> 渲染 -> 事件 -> newState ）
- 状态是一个包含整个 HTML 的简单字符串
- 不使用编辑器内的语法，但我们可以在调用
tinymce.getContent时添加语法注释
（随意在此处添加任何其他技术原型）
我正在创建这个问题，以便我们可以比较每种方法的优缺点，以帮助我们决定选择实施哪种方法。
youknowriad
所有3条评论
以下是我对这两个原型的感受：
原型 1：
优点：
- 在编辑器上下文之外使用块似乎更容易
- 我个人更喜欢将状态作为对象，状态的外部操作（TinyMCE 中未内置的操作）似乎更容易实现。
缺点：
- 多块选择似乎不可能实现。 Ctrl+A 是每个块。
原型 2：
优点：
- 多块选择
- 更容易实现全文UI的感觉
缺点
- 更难在编辑器外重用块？
- TinyMCE 可以覆盖块内容中的一些默认行为https://wordpress.slack.com/archives/core-tinymce/p1487169326000067
基于这个实验原型https://github.com/WordPress/gutenberg/pull/113，我尝试采用一种混合方法，我们使用 TinyMCE 作为包装器，但根据状态变化重新呈现其内容。 经过一番探索，这种方法感觉就像是在尝试重新创建 DraftJS 或 ProseMirror。 而且我认为这不是使用 TinyMCE 的正确方法。
youknowriad
于 2017-02-23
感谢您创建这张票。
在进行比较时，我们还应该考虑 #3，因为这似乎取决于我们选择的方法。
jasmussen
于 2017-02-23
我认为 Prototype 2 是要走的路，虽然它可能更痛苦，因为它会涉及更多 TinyMCE 工作，最终它可能是目前最好的方法。
更难在编辑器外重用块？
我认为这不会是 Prototype 2 的缺点，只要用于定义块类型和控制类型的 API 提供足够的数据供 TinyMCE 以外的其他东西使用。 我认为我们应该开发一个块类型/控制类型定义 API，用于提供高度自定义的 TinyMCE 实例。 来自块类型/控制类型的数据也可用于在未来潜在地提供其他内容。
尽管它可能不太好吃，但 Prototype 2 反映了 WordPress 的大部分工作方式，而 TinyMCE 做了很多，这对我来说是一条非常明智的前进道路。
BE-Webdesign
于 2017-03-21
相关问题
JohnPixle
·
3评论
bradyvercher
·
3评论
aaronjorbin
·
3评论
hedgefield
·
3评论
maddisondesigns
·
3评论
最有用的评论
以下是我对这两个原型的感受：
原型 1：
优点：
缺点：
原型 2：
优点：
缺点
基于这个实验原型https://github.com/WordPress/gutenberg/pull/113，我尝试采用一种混合方法，我们使用 TinyMCE 作为包装器，但根据状态变化重新呈现其内容。 经过一番探索，这种方法感觉就像是在尝试重新创建 DraftJS 或 ProseMirror。 而且我认为这不是使用 TinyMCE 的正确方法。