前言
上周通过对wangEditor源码的学习，从零撸了一个精简版的miniEditor。本篇主要是对一些目前常见的富文本编辑器功能的一些调研总结及简单的发散思考，增进个人对富文本编辑器相关生态的了解。
富文本编辑器的实现方式
目前主要的富文本编辑器的实现方式大概有如下几种
基于HTML DOM的Contenteditable属性
使用基于HTML DOM的Contenteditable属性，目前主要有如下两种方式
实现方式一
基于HTML DOM的Contenteditable属性及使用document.execCommand来实现 使用该种方式的有如wangEditor,CKEditor等，document.execCommand方式的优缺点如下
主要优点
- 基于浏览器原生编辑能力，输入非常流畅
- 没有令人头疼的IME（组合输入）问题
- 开发实现成本相对其他方式减低，也相对更简单
主要缺点
- 浏览器兼容问题，不同浏览器生成的dom无法统一
- 相同操作不同浏览器可能有不同的实现（比如基本的加粗、斜体、Enter），很难实现表现和数据完全统一
- 视图逻辑无法抽象成一些通用的数据模型管理
- 因为无法视图抽象成数据模型，对于协同功能支持困难
实现方式二
基于HTML DOM的Contenteditable属性，通过数据模型与视图交互，自定义command 该方式需要设计一套内部使用的数据模型，与用户在编辑器内所见的视图相绑定；通过捕获用户的操作行为，将原有的修改dom调整为修改数据模型，再将更新后的状态映射至视图，来实现编辑器的所见即所得的效果。实现方式和现在流行的MVVM数据驱动渲染思路类似。
- 使用该方式的有比如Quill,ProseMirror,Draft.js,Slate.js。这些框架的主要区别在于内部数据模型定义不同，及一些视图框架不同。当然还有代码的组织方式和实现方式也都有各自很大的区别。具体的细节，可以仔细阅读下开源富文本编辑器技术的演进
主要优点
解决了document.execCommand 中存在的一些副作用，如
- 在相同的操作在不同的浏览器实现一致
- 视图逻辑通过统一的数据模型管理
- 后续对于协同功能支持更容易
主要缺点
相对于前一种，目前能想到的最大的缺点应该就是实现复杂度会更高一些。其他更具体的缺点因了解的还不够深入，后续再总结。
不使用Contenteditable
自主实现选区光标和内容排版及编辑等功能，完全不依赖浏览器编辑功能。
- 该方式目前还未看到有开源的富文本编辑器方案，闭源的大概有Google Doc和腾讯文档等。腾讯文档富文本功能根据其展示的dom简单的了解了下，可能是基于canvas实现了文档编辑相关的功能，文档本身的内容具体用了什么样的模型和详尽的架构可能需要等腾讯文档内部的大佬流出一些相关的分享文档。
- 抛开富文本功能，单纯只看自主实现编辑功能的方案，调研了下开源的CodeMirror和VSCode的monaco。其中CodeMirror的最初版本代码较少，近期会整理一个精简版用于学习自定义编辑功能的实现方式。
其他
除了以上方式，比如iframe，textarea也可以实现简单的富文本功能，目前主流的富文本编辑器应该都没有采用这些方式，这里不做讨论。
发散
上述富文本编辑器都是基于web的实现方式，百度上对富文本编辑的定义也是将其定义为内嵌于浏览器的所见及所得的文本编辑器。私以为富文本编辑器应该不止于web浏览器，其可以作为一个标准在不同的平台或者宿主实现。嵌入的宿主可以是浏览器，也可以是原生app，原生桌面应用。标准一致实现方式可以脱离web。数据模型抽离出来的富文本编辑器，再针对不同的平台实现编辑功能，可以更好的实现体验更佳的富文本编辑功能。
最后
个人目前是一个富文本编辑器的初学者，以上总结整理难免会有错误或者描述不正确的地方，欢迎指正拍砖。
