共计 4950 个字符，预计需要花费 13 分钟才能阅读完成。
在开发有道云笔记的新版编辑器的过程中，咱们遇到很多理论问题，愈发感觉到这是一个十分有深度的前端技术畛域，所以咱们将新版编辑器的技术选型、架构和局部实现细节拿进去分享给大家，心愿对大家开发富文本编辑器、做简单零碎的架构设计有肯定参考意义。
作者 / 金鑫
编辑 / Ryan
起源 / 有道技术团队（ID: youdaotech）
1. 富文本编辑器背景
1.1 什么是编辑器
编辑器在前端开发畛域是指能够提供给用户编辑 纯文本、富文本、代码、多媒体 内容等的功能模块，例如以云笔记为例，编辑器指下图中绿色的区域。
有道云笔记编辑器界面
编辑器个别由 编辑区域、光标、工具栏、右键菜单 等功能模块组成，个别都蕴含 编辑文字、设置文字款式、设置段落款式、插入多媒体内容、撤销重做、复制剪切粘贴 等性能。
1.2 编辑器倒退简史
编辑器的由来能够追溯到打字机时代，下图是一个常见的打字机。
咱们能够将打字机的结构与编辑器进行类比，打字机的纸张对应于编辑器的编辑，打字机的游标对应于编辑器的光标，甚至敲击键盘的体现，编辑器也与打字机一脉相承：
- 当敲击 字母 时，在光标后输出该字符；
- 当敲击 空格键 时，在游标之后插入空格；
- 当敲击 回格键 时，删除游标之前的字符；
- 当敲击 换行键 时，游标换到下一行开始；
而在计算机中，呈现的最早的是文本编辑器，例如咱们在 Linux 零碎中罕用的 vi，vim，emacs 等，它们能够对纯文本数据进行编辑，并引入了撤销重做、复制剪切粘贴、查找替换等编辑器的外围性能。
随着用户图形界面的衰亡，人们对于文本的编辑不止满足于纯文本了，还须要给文本段落加上各种格局和排版信息。
同时，人们对于在文档中插入图片、图形、表格等更丰盛格局的需要也越来越多。为了满足这些需要，富文本编辑器就呈现了，其中的集大成者就是微软的 Word 和金山的 WPS。
Word 和 WPS 能够说将桌面客户端中的富文本编辑器做到了极致，至今也是功能强大的富文本编辑器。
然而它们的设计初衷就是做一款单机的文字处理软件，天然会遇到不反对互联网上的音视频格局、存储备份依附本地计算机的文件系统、多人合作依附文件拷贝等问题。
在互联网遍布千家万户的今日，人们反而不太须要 Word 提供的交互简单的各种弱小性能，而是须要反对更多互联网数据格式、存储备份更加不便、可能提供多人协同编辑性能的轻量级富文本编辑器。
基于浏览器的富文本编辑器就是在这样的设计思路下产生的，其中的代表产品有 Google Docs、有道云笔记、印象笔记、石墨文档等。
这些基于浏览器的富文本编辑器都有以下 特点：
- 利用 Web 技术开发，须要在浏览器环境中应用；
- 性能绝对 Word 更加简略，只保留了最罕用的富文本编辑性能；
- 反对图片、附件、视频、音频、地图等多种互联网资源；
- 能够将文档备份在网盘中，实现多端同步；
- 文档能够分享查看，能够进行多人实时协同编辑。
当然基于浏览器的富文本编辑器，也是通过了几轮的技术迭代和翻新，才到了明天这种百花齐放的场面。
1.3 基于浏览器的富文本编辑器四因素
在古代的浏览器框架下，利用 Web 技术开发一款富文本编辑器，个别采纳经典 MVC 模型，依据数据模型渲染视图，视图操作通过控制器批改数据模型。具体要解决以下四个问题：
模型：
模型蕴含内存模型和存储模型。存储模型是数据存储、同步和备份时的模型，须要思考带宽、存储体积、模型序列化效率、模型正确性验证效率等因素。内存模型则是数据渲染时的模型，构造个别比存储模型简单，会在存储模型的根底上增加其余渲染时须要用到的属性。
渲染：
渲染指如何将内存模型渲染成 Web 页面。所有的基于浏览器富文本编辑器都将内存模型渲染成为了 HTML 页面。然而它们在排版上的策略略有不同，大多数编辑器都采纳了基于 HTML 和 CSS 的排版形式，也有多数编辑器本人实现了排版引擎，例如 Google Docs。
编辑：
编辑指如何提供编辑区域让用户在编辑区域编辑文档，以及如何感知用户编辑区域的编辑动作告诉控制器以批改数据模型。浏览器提供了 contentEditable 的属性能够把元素变为可编辑状态，大部分编辑器都是以这个思路进行编辑的，并且它们能够拦挡 contentEditable 元素的事件，将事件告诉给控制器。也有多数编辑器本人实现了编辑区域和事件零碎，例如 Google Docs。
指令：
指控制器依据收到的编辑区域的编辑动作，生成对应指令批改内存模型，内存模型得以更新实现循环。这部分与数据模型相干，如果数据模型是 HTML，编辑器能够通过 execCommand 间接批改 HTML 数据，如果是自定义数据，监听或拦挡编辑区域上的事件，也能够揣测用意生成出批改数据模型的指令。通过指令批改数据，能够更不便的实现撤销重做、历史版本复原、协同编辑等性能。
1.4 基于浏览器的富文本编辑器技术演进
基于以上四个问题，能够将基于浏览器的富文本编辑器划分为四代：
第一代：
齐全基于浏览器 API 设计，数据模型间接采纳 HTML 数据，渲染用原生 HTML，编辑区域用 contentEditable 生成，通过 execCommand 执行浏览器自带的批改 HTML 数据的指令。
这类编辑器个别都呈现在各类《XX 行代码教你实现富文本编辑器》的博客里，根本没有成熟的开源编辑器或者商用编辑器采纳这一种设计形式。它们的次要问题处在 execCommand 接口上：
- 只提供了无限的几个命令，例如 execCommand 就没有方法反对插入待办列表。
- 提供的命令有些有性能受限，例如 ‘fontSize’ 命令只能反对 1-7，导致不能自定义字体的大小。
- 批改的后果与浏览器无关，例如 ‘bold’ 命令在一些浏览器上会给选区中的文字增加 标签，而在另一些浏览器上则会增加 标签。
第二代：
因为 execCommand 性能上的限度，第二代的编辑器广泛摈弃了用浏览器的 execCommand 接口间接批改 HTML 文档的方法，而是用本人实现的 execCommand 和指令批改 HTML 文档，这样做就能够实现更加灵活多样的性能。
这类编辑器的次要问题是：不同的 HTML 构造可能示意的含意一样。例如上面两行 HTML 都示意一段既加粗又斜体的文字，然而他们的 HTML 构造却不一样，这样对比拟数据是否一样就变得十分艰难。
第三代：
针对 HTML 含意不统一的问题，第三代编辑器则摈弃了既用 HTML 做文档模型，又用 HTML 做渲染的策略，而是采纳自定义的数据模型，例如 XML 数据模型或者 JSON 数据模型。同样的数据模型渲染生成的 HTML 一样，自定义的操作则能够保障同样的操作批改之后的文档模型也是一样的。
目前常见的编辑器产品例如：有道云笔记、石墨文档等，以及开源的编辑器库例如 Slate、Draft、Quill 等，都是第三代编辑器，它们曾经可能满足大多数利用场景。然而因为渲染出的页面中，可编辑区域还是基于 contentEditable，须要依据拦挡的事件判断用户行为，生成对应的指令批改数据模型。一旦有用户数据没有拦挡，或者解决的行为不对，用户的行为就可能间接批改了 contentEditable 的元素，导致数据和视图的不统一。因而产生的 bug 定位和修复都比拟难，在编辑器的挪动端适配中经常出现。
第四代：
为了解决 contentEditable 引起的不可控事件，以 Google Docs 为代表的第四代编辑器则彻底摈弃的 contentEditable，本人实现排版引擎。排版引擎管制了文档的页面和布局，将数据渲染成为页面上的 HTML。同时因为摈弃了 contentEditable，还须要解决实现光标和选区的绘制、监听文字输出事件等技术问题，才能够做到和浏览器相似的编辑体验。
第四代编辑器绝对于第三代，长处是彻底解决了 contentEditable 引起的 bug，有更好的可扩展性。对应的代价是开发难度更高、体验不如原生、可能会遇到性能问题。目前只有 Google Docs 等采纳了这种架构开发编辑器。
2. 云笔记新版编辑器技术选型
依据上节所述的实现富文本编辑器的四因素，咱们总结了四代编辑器的技术选型，如下表所示：
有道云笔记新版编辑器综合了我的项目的可扩展性和实现难度，作出了以下的 技术选型：
- 模型：自定义的 JSON 数据格式作为内存模型，它的压缩版本作为存储模型；
- 渲染：借助浏览器排版，用 React 框架渲染视图；
- 编辑：不依赖 contenteditable，拦挡浏览器事件判断用户交互，本人实现了光标和选区；
- 指令：实现了丰盛的自定义的富文本编辑指令，从新实现了 execCommand 执行指令。
2.1 模型
有道云笔记新版编辑器采纳了自定义的 JSON 数据格式作为内存模型。存储模型与内存模型根本对应，是内存模型的压缩版本，这样能够缩小在数据序列化和反序列化过程中呈现的谬误。
文档模型：
新版编辑器的内存模型采纳了 文档 - 段落 - 文本 的三层模型，顶层对象是文档（下图黄色区域），一篇文档蕴含多个段落（下图蓝色区域），每个段落中有至多一个文本（下图红色区域）。
对于三层的文档模型，咱们能够很天然的想到用树的构造来示意它，如下图所示：
因为 JSON 格局人造的就能够示意嵌套的树状构造，所以咱们的三层文档模型能够示意为以下的 JSON 构造：
富文本示意：
对于富文本编辑器的数据模型，须要思考文本的行内款式和段落款式：
行内款式是作用于文字的款式，每个文字都可能有不同的行内款式，例如文字的粗体、斜体、文字色彩、背景色、字体、字号等
段落款式是用作与段落的款式，整段文字只会有一个段落款式，例如对齐形式、行高、段落缩进等。
因为咱们三层文档模型中段落是独自一层，有对应的段落节点，所以对于段落款式只须要在段落节点上增加示意段落款式的字段，咱们是在 paragraph 增加了 data 字段，其中增加了 style 属性示意该段落的段落款式，如下图所示：
如果要示意行内款式，目前文本节点中只保留一个 content 字段就没有方法胜任了，须要将它拆分为一个一个字符在每个字符上增加示意行内款式的字段，例如咱们能够用一个 chars 数组，外面的每个元素示意一个字符，text 字段示意字符的内容，marks 数组示意字符上的行内款式，如下图示意 a rich text。
叶子节点：
上述的富文本行内款式的示意办法中，咱们能够看到 rich 的款式粗体、斜体、红色背景色保留在了 r, i, c, h 四个字符上，存在着冗余数据。咱们参考了 HTML 渲染后果和局部开源编辑器的实现定义了合并规定。
如果间断的字符节点，具备完全相同的行内款式，则它们能够合并成一个叶子节点。
例如下面的例子里，r, i, c, h 四个字符间断且具备完全相同的行内款式，它们是能够合并成为一个叶子节点的。相似的“a”、“text”也别离能够合并成叶子节点，所以咱们能够将文本节点简化示意为：
综上，简化后反对行内款式的文本节点也是一个树状构造，它蕴含一个或多个叶子节点，每个叶子节点蕴含文本的内容和这些内容独特的行内款式，且相邻的叶子节点的行内款式必须不完全一致，如下图所示：
2.2 渲染
云笔记新版编辑器仍旧采纳了浏览器进行排版渲染，没有像 Google Docs 那样自研排版引擎，起因是咱们认为浏览器的排版引擎曾经足够弱小，根本满足日常的文本编辑需要，只有诸如图片的文字盘绕、分页、分栏等比拟高级的性能无奈实现，而自研排版引擎须要大量的开发和测试工作量，还可能会产生性能问题，所以咱们临时还是用来浏览器进行排版和渲染。
咱们采纳了 React 框架，采纳了组件化的形式渲染数据模型。针对文档 - 段落 - 文本的三层数据模型，以及文本节点的叶子模型，咱们设计了对应 React 组件嵌套进行渲染，如下图所示：
- Document 组件渲染文档数据。
- Paragraph 组件渲染段落数据，它是 Document 组件的子组件。
- Text 组件渲染文本数据，它是 Paragraph 组件的子组件。
- Leaf 组件渲染叶子节点，它是 Text 组件的子组件。
对于叶子节点蕴含的文本片段和行内款式，只须要渲染成一个带 style 属性的 <span> 标签就能够了，这也印证了咱们设计的富文本模型，简化了富文本的渲染逻辑，使得富文本渲染代码变得十分的轻量化。
以上是本期文章的全部内容。
下周三，咱们将推送《有道云笔记新版编辑器架构设计（下）》，持续分享对于 编辑 和指令 的内容，并进一步解说新编辑器的分层架构。
敬请关注 有道技术团队。
– END –
