一起跳进富文本编辑器的大坑

引子

编辑器2.png

编辑器3.png

富文本编辑器的核心：contentEditable 和 document.execCommand

当一个HTML元素的contenteditable属性被设置为true时，document.execCommand() 方法便可使用。通过该方法，你可以运行相关commands 来操作可编辑区域的内容。




Rich Text Editor



































Lorem ipsum
 Show HTML

Let's go!

L0阶段

远古时代的前端开发者应该会对这样的图有那么一丝丝印象（暴露年龄了）（那时候还没有什么UI可言

687474703a2f2f6665782e62616964752e636f6d2f75656469746f722f646f632f696d616765732f64656d6f2e706e67.png

没错，图上就是从前很有名的UEditor（百度出品的开源富文本编辑器），同期同类型编辑器还有CKEditor 1-4（遥远的2008年）。

我们来回顾下L0阶段的富文本编辑器是怎样实现的：

用contentEditable 实现内容的可编辑。
基于document.execCommand和自定义扩展的execCommand去去操作DOM实现富文内容的修改。
辅以一些DOM的嵌套规则（dtd）和复杂数据输入（如粘贴）的过滤规则来约束数据的正确性。
输出富文本内容是HTML字符串。
简单点来说就是contentEditable和document.execCommand我全都要，可以简单理解为引言例子的扩展。

L0的问题：
L0的问题很有代表性

兼容问题：不同浏览器的表现不同
拖拽、复制黏贴、删除等不可控的交互带来的数据混乱问题
对协同编辑器支持很困难
定制空间有限

L1 阶段

Quill.js 2012

依赖DOM的contentEditable特性
不直接操作DOM，而是通过模型API
对DOM TREE 和模型操作进行抽象

Delta来描述编辑器的内容及其变化（协同编辑有路子了）

  "ops": [
      {
          "insert": "Hello "
      },
      {
          "attributes": {
              "bold": true
          },
          "insert": "Quill"
      },
      {
          "insert": "！"
      }
  ]

} ```

本质是OT模型的一种实现

OT（Operation Transformation），操作转换，协同技术中用来保持不同的数据副本一致性的一种方法。在不同的终端，根据操作顺序的不同，对操作进行调整，以保持数据一致性.

石墨文档的富文本是基于Quill开发的。

ProseMirror 2015

依赖DOM的contentEditable特性
JSON数据描述富文本内容
引入不可变数据（统一了内容的修改，把原来的更改DOM的方式改为对不可变数据的修改）以及Virtual DOM的概念（前端架构的feel来了）
输出是纯JSON
很有代表行的L1阶段编辑器：代理了浏览器大部分的默认行为，把操作转换为数据的变换，进而更新UI。

Draft.js

React 作为UI层
主流编程思想使用状态管理的思想管理富文本数据
知乎的富文本编辑器基于Draft.js开发。

Slate

目前仍然是beta版本
大量借鉴前者优点
插件是一等公民，可以完全定制编辑体验，去建立像 Medium 或是 Dropbox 这样复杂的编辑器，而不必对各种类库进行猜测。
嵌套文档模型，可协作的数据模型。
非开箱即用，适用于构建自己的编辑器。

L1的特点总结：

基于contentEditable特性
对富文本内容有了一定的抽象
引入了主流的编程思想

问题：仍然依赖浏览器的可编辑能力

L2 编辑器的未来

不依赖任何浏览器的编辑功能，自主实现光标、选区、排版。
Google Docs
Office Word Online
iCloud Pages
WPS 在线版
无开源项目

总结

从L0-L1-L2，我们可以看到从完全依赖浏览器的编辑功能，到部分依赖编辑功能，再到完全抛弃浏览器的编辑功能，这中间是日益丰富的编辑器需求在推动技术的进步。也可以看到前端技术变化的影子。

大厂是怎么做的

聊到这里，肯定有人会问，语雀用的哪款编辑器？怎么上面都没有看到？
我在对编辑器选型的时候，第一反应就是直接对标语雀，功能全，使用感也很好。
然而结果是，语雀富文本编辑器是自主开发的并且不会开源。。。不过也有一些分享一些编辑器开发的经验。

原型阶段：CodeMirror（L0）+React+antd——优雅的markdown（应用层服务器用了Egg）在线编辑器

语雀1.png

内部服务阶段：Slate（L1）+React+antd——正式的富文本编辑器

语雀2.png

商业化阶段：自研编辑器（Lake Editor）+React——现在我们用的语雀

语雀3.png

内部服务阶段到商业化阶段的转型：
开始是基于slate开发的，但是后面发现了很多问题，例如难以修复，页面崩溃，光标错乱，粘贴卡死等等。还有很多个性化需求实现成本高。于是后面就转为重写L1编辑器。

（我个人理解语雀遇到的问题其实所有使用开源富文本编辑器的都会遇到，毕竟随便打开一个star有几K的还在频繁更新的编辑器都能看到成百上千的issues（open状态））。

数据格式：在HTML基础上扩展
卡片机制：承接组件的扩展，在编辑器里独立的一块区域
开发模式：Hybrid混合开发，编辑区域用原生JS，UI层用React
技术原理：基于contentEditable，通过Range API 对选中的内容进行操作
通过 canvas 实现了表格编辑器，通过 SVG 实现了思维导图编辑器

语雀4.png

多人实时协同：
市面产品：Google Docs CKEditor 5 Slate Quill 都用了OT（Operation Transformation）或者类似的技术，将操作转化为OP，发送到协作服务，再转发给其他在线用户。
最后的实现：
OT服务：基于ShareDB
数据格式：JSONML
技术原理：通过MutationOBserver API 监听编辑器的DOM树变更，生成JSON格式的OP，发送到ShareDB，更新JSONML数据。同时将OP发送到其他用户，将OP转化成DOM操作方法之后执行。

最后语雀是JavaScript 全栈进行研发的，感兴趣的同学可以深入研究最后的附文。

聊聊实操

说了这么多，我们自己开发项目的时候怎么选呢。

语雀5.png

但是我自己的经验是：普通的业务需求，其实需要我们提供一个稍微美观又开箱即用的富文本编辑器即可。只要满足需求即可。二次开发越少越好。还有一点就是要看下最近的维护时间。

https://github.com/topics/wysiwyg-editor
这个话题下面有很多可选的编辑器，大家可以找自己用的顺手的。

目前正在开发的CCTASK知乎库，暂时选择了CKEditor5，之前是看中他功能比较全，并且支持在线多人协同，但是现在发现协同功能需要CKCloud云服务支持。

使用的时候，可以用在线工具配置需要的插件，再引入项目，进行菜单栏的配置。
图片上传功能需要写一个MyUploadAdapter导出一个插件再进行引用。
目前遇到的问题只是文档资源较少，后面还需要时间的验证。

ckeditor.png

附录：参考文章
https://zhuanlan.zhihu.com/p/268366406
https://max.book118.com/html/2019/1027/8004023067002060.shtm
https://www.yuque.com/seeconf/2020/dn74yy
https://www.yuque.com/preview/yuque/0/2020/pdf/84135/1578380717315-17b401af-78d5-4eaf-a4ed-b3a93ccb91d2.pdf
https://ckeditor.com/docs/index.html