有道云笔记新版编辑器架构设计（上）

编辑器在前端开发领域是指可以提供给用户编辑纯文本、富文本、代码、多媒体内容等的功能模块，例如以云笔记为例，编辑器指下图中绿色的区域。

编辑器的由来可以追溯到打字机时代，下图是一个常见的打字机。

而在计算机中，出现的最早的是文本编辑器，例如我们在 Linux 系统中常用的 vi，vim，emacs 等，它们可以对纯文本数据进行编辑，并引入了撤销重做、复制剪切粘贴、查找替换等编辑器的核心功能。

随着用户图形界面的兴起，人们对于文本的编辑不止满足于纯文本了，还需要给文本段落加上各种格式和排版信息。

同时，人们对于在文档中插入图片、图形、表格等更丰富格式的需求也越来越多。为了满足这些需求，富文本编辑器就出现了，其中的集大成者就是微软的 Word 和金山的 WPS。

Word 和 WPS 可以说将桌面客户端中的富文本编辑器做到了极致，至今也是功能强大的富文本编辑器。

但是它们的设计初衷就是做一款单机的文字处理软件，自然会遇到不支持互联网上的音视频格式、存储备份依靠本地计算机的文件系统、多人协作依靠文件拷贝等问题。

在互联网遍及千家万户的今日，人们反而不太需要 Word 提供的交互复杂的各种强大功能，而是需要支持更多互联网数据格式、存储备份更加方便、能够提供多人协同编辑功能的轻量级富文本编辑器。

基于浏览器的富文本编辑器就是在这样的设计思路下产生的，其中的代表产品有 Google Docs、有道云笔记、印象笔记、石墨文档等。

这些基于浏览器的富文本编辑器都有以下特点：

当然基于浏览器的富文本编辑器，也是经过了几轮的技术迭代和创新，才到了今天这种百花齐放的局面。

在现代的浏览器框架下，利用 Web 技术开发一款富文本编辑器，一般采用经典 MVC 模型，根据数据模型渲染视图，视图操作通过控制器修改数据模型。具体要解决以下四个问题：

完全基于浏览器 API 设计，数据模型直接采用 HTML 数据，渲染用原生 HTML，编辑区域用 contentEditable 生成，通过 execCommand 执行浏览器自带的修改 HTML 数据的指令。

这类编辑器一般都出现在各类《XX 行代码教你实现富文本编辑器》的博客里，基本没有成熟的开源编辑器或者商用编辑器采用这一种设计方式。它们的主要问题处在 execCommand 接口上：

• 只提供了有限的几个命令，例如 execCommand 就没有办法支持插入待办列表。

• 提供的命令有些有功能受限，例如 'fontSize' 命令只能支持 1-7，导致不能自定义字体的大小。

• 修改的结果与浏览器有关，例如 'bold' 命令在一些浏览器上会给选区中的文字添加<b>标签，而在另一些浏览器上则会添加<strong>标签。

由于 execCommand 功能上的限制，第二代的编辑器普遍抛弃了用浏览器的 execCommand 接口直接修改 HTML 文档的办法，而是用自己实现的 execCommand 和指令修改 HTML 文档，这样做就可以实现更加灵活多样的功能。

这类编辑器的主要问题是：不同的 HTML 结构可能表示的含义一样。例如下面两行 HTML 都表示一段既加粗又斜体的文字，但是他们的 HTML 结构却不一样，这样对比较数据是否一样就变得非常困难。

针对 HTML 含义不一致的问题，第三代编辑器则抛弃了既用 HTML 做文档模型，又用 HTML 做渲染的策略，而是采用自定义的数据模型，例如 XML 数据模型或者 JSON 数据模型。同样的数据模型渲染生成的 HTML 一样，自定义的操作则可以保证同样的操作修改之后的文档模型也是一样的。

第四代编辑器相对于第三代，优点是彻底解决了contentEditable 引起的 bug，有更好的可扩展性。对应的代价是开发难度更高、体验不如原生、可能会遇到性能问题。目前只有 Google Docs 等采用了这种架构开发编辑器。

根据上节所述的实现富文本编辑器的四要素，我们总结了四代编辑器的技术选型，如下表所示：

有道云笔记新版编辑器综合了项目的可扩展性和实现难度，作出了以下的技术选型：

• 模型：自定义的 JSON 数据格式作为内存模型，它的压缩版本作为存储模型；

• 渲染：借助浏览器排版，用 React 框架渲染视图；

• 编辑：不依赖 contenteditable，拦截浏览器事件判断用户交互，自己实现了光标和选区；

• 指令：实现了丰富的自定义的富文本编辑指令，重新实现了 execCommand 执行指令。

新版编辑器的内存模型采用了文档-段落-文本的三层模型，顶层对象是文档（下图黄色区域），一篇文档包含多个段落（下图蓝色区域），每个段落中有至少一个文本（下图红色区域）。

对于三层的文档模型，我们可以很自然的想到用树的结构来表示它，如下图所示：

由于 JSON 格式天然的就可以表示嵌套的树状结构，所以我们的三层文档模型可以表示为以下的 JSON 结构：

对于富文本编辑器的数据模型，需要考虑文本的行内样式和段落样式：

行内样式是作用于文字的样式，每个文字都可能有不同的行内样式，例如文字的粗体、斜体、文字颜色、背景色、字体、字号等

段落样式是用作与段落的样式，整段文字只会有一个段落样式，例如对齐方式、行高、段落缩进等。

由于我们三层文档模型中段落是单独一层，有对应的段落节点，所以对于段落样式只需要在段落节点上添加表示段落样式的字段，我们是在 paragraph 添加了 data 字段，其中添加了 style 属性表示该段落的段落样式，如下图所示：

如果要表示行内样式，目前文本节点中只保存一个 content 字段就没有办法胜任了，需要将它拆分为一个一个字符在每个字符上添加表示行内样式的字段，例如我们可以用一个 chars 数组，里面的每个元素表示一个字符，text 字段表示字符的内容，marks 数组表示字符上的行内样式，如下图表示 a rich text。

上述的富文本行内样式的表示方法中，我们可以看到rich的样式粗体、斜体、红色背景色保存在了 r, i, c, h 四个字符上，存在着冗余数据。我们参考了HTML渲染结果和部分开源编辑器的实现定义了合并规则。

如果连续的字符节点，具有完全相同的行内样式，则它们可以合并成一个叶子节点。

例如上面的例子里，r, i, c, h 四个字符连续且具有完全相同的行内样式，它们是可以合并成为一个叶子节点的。类似的 “a ”、“ text” 也分别可以合并成叶子节点，所以我们可以将文本节点简化表示为：

综上， 简化后支持行内样式的文本节点也是一个树状结构，它包含一个或多个叶子节点，每个叶子节点包含文本的内容和这些内容共同的行内样式，且相邻的叶子节点的行内样式必须不完全一致，如下图所示：

云笔记新版编辑器依旧采用了浏览器进行排版渲染，没有像 Google Docs 那样自研排版引擎，原因是我们认为浏览器的排版引擎已经足够强大，基本满足日常的文本编辑需求，只有诸如图片的文字环绕、分页、分栏等比较高级的功能无法实现，而自研排版引擎需要大量的开发和测试工作量，还可能会产生性能问题，所以我们暂时还是用来浏览器进行排版和渲染。

我们采用了 React 框架，采用了组件化的方式渲染数据模型。针对文档-段落-文本的三层数据模型，以及文本节点的叶子模型，我们设计了对应 React 组件嵌套进行渲染，如下图所示：

• Document 组件渲染文档数据。

• Paragraph 组件渲染段落数据，它是 Document 组件的子组件。

• Text 组件渲染文本数据，它是 Paragraph 组件的子组件。

• Leaf 组件渲染叶子节点，它是 Text 组件的子组件。

对于叶子节点包含的文本片段和行内样式，只需要渲染成一个带 style 属性的<span>标签就可以了，这也印证了我们设计的富文本模型，简化了富文本的渲染逻辑，使得富文本渲染代码变得非常的轻量化。