从零实现富文本编辑器系列文章
## Why?
那么为什么要从零设计实现新的富文本编辑器，编辑器是公认的天坑，且当前已经有很多优秀的编辑器实现。例如极具表现力的数据结构设计`Quill`、结合`React`视图层的`Draft`、纯粹的编辑器引擎`Slate`、高度模块化的`ProseMirror`、开箱即用的`TinyMCE/TipTap`、集成协同解决方案的`EtherPad`等等。
我也算是比较关注于各类富文本编辑器的实现，包括在各个站点上的编辑器实现文章我也会看。但是我发现这其中极少有讲富文本编辑器的底层设计，绝大多数都是讲的应用层，例如如何使用编辑器引擎实现某某功能等。虽然这些应用层的实现本身也会有一定复杂性，但是底层的设计却是更值得探讨的问题。
此外，我觉得富文本编辑器很类似于低代码的设计，准确来说是`No Code`的一种实现。本质上低代码和富文本都是基于`DSL`的描述来操作`DOM`结构，只不过富文本主要是通过键盘输入来操作`DOM`，而无代码则是通过拖拽等方式来操作`DOM`，我想这里应该是有些共通的设计思路。
而我恰好前段时间都在专注于编辑器的应用层实现，在具体实现的过程中也遇到了很多问题，并且记录了相关文章。然而在应用层实现的过程中，遇到了很多我个人觉得可以优化的地方，特别是在数据结构层面上，希望能够将我的一些想法应用出来。而具体来说，主要有下面的几个原因:
### 编辑器专栏
纸上得来终觉浅，绝知此事要躬行。
我的博客是从`20`年开始写的，记录的内容很多，基本上是想到什么就写什么，毕竟是作为平时学习的记录。然后在`24`年写了比较多的富文本编辑器的文章，主要是整理了平时遇到的问题以及解决方案，集中在应用层的设计上，例如:
- [初探富文本之文档虚拟滚动](https://github.com/WindRunnerMax/EveryDay/blob/master/RichText/初探富文本之文档虚拟滚动.md)
- [初探富文本之OT协同算法](https://github.com/WindRunnerMax/EveryDay/blob/master/RichText/初探富文本之OT协同算法.md)
- [...](https://github.com/WindRunnerMax/EveryDay#richtext)
此外，前段时间还研究了`slate`富文本编辑器相关的实现，并且也给`slate`的仓库提过一些`PR`。还写了一些`slate`相关的文章，并且还基于`slate`实现了一个文档编辑器，同样也是比较关注于应用层的实现，例如:
- [WrapNode数据结构与操作变换](https://github.com/WindRunnerMax/EveryDay/blob/master/RichText/WrapNode数据结构与操作变换.md)
- [Node节点与Path路径映射](https://github.com/WindRunnerMax/EveryDay/blob/master/RichText/Node节点与Path路径映射.md)
- [...](https://github.com/WindRunnerMax/EveryDay#richtext)
在实现了诸多的应用层的功能之后，发现整个编辑器有很多可以深入研究的地方。特别是有些实现看似很理所当然，但是仔细研究起来会发现这其中有很多细节可以探究，例如在`DOM`结构后常见的零宽字符、`Mention`节点的渲染等等，这些内容都可以单独拿出来记录文章，这其实就是我想从零实现编辑器的最重要原因。
`24`年开始写了很多业务上的东西，到了`25`年就略感题穷，而目前我也没有别的擅长的方面，由此写编辑器相关的内容是比较好的选择，这样对于文章的选题也会简单些。不过，虽然想的是深入写编辑器相关的内容，但是在平时遇到问题的时候，还是会记录下来，例如最近有个基于`immer`配合`OT-JSON`实现的状态管理的想法可以实现。
而对于编辑器的具体实现，我目前的目标是实现可用的编辑器，而不是兼容性非常好且功能完备的编辑器。主要是现在已经有非常多优秀的编辑器实现，且有很多生态插件可以支持，能够满足大部分的需求。目前我想实现的编辑器主要是兼容`Chrome`浏览器即可，移动端的问题暂时不会考虑。不过，如果能够将编辑器做得比较好的话，自然可以去做兼容性适配。
不过目前还是试探性地来设计并实现编辑器，期间必然会遇到很多问题，这些问题也将会成为专栏的主体内容。最开始的时候，我是准备将编辑器完善后再开始撰写文章，后来发现设计过程中的历史方案同样很有价值，因此决定将设计过程也一并记录下来。如果将来真的能够将编辑器适用于生产环境，那么这些文章就能够溯源到模块为什么这么设计，想必也是极好的。整体来说，我们不能一口吃成胖子，但是一口一口吃却是可以的。
### 深入编辑器
这部分是让我想起来一句话：我们富文本编辑器是这样的，你不写你不懂。
编辑器是个非常注重细节的工程，很多时候都需要深入研究浏览器的`API`，例如`document`上的`caretPositionFromPoint`方法，用以获取当前某个点所在的选区位置，通常用于拖拽文本后的落点定位。除此之外，还有很多选区相关的`API`，例如`Selection`、`Range`等等，这些都是编辑器实现的基础。
那么深入编辑器底层就是很有意义的事情，很多时候我们都需要跟浏览器打交道，即使是对我们平时的业务开发也会有价值。在这里我想聊一下编辑器中的零宽字符，以此例学习编辑器的细节设计，这是一个非常有意思的话题，类似这种内容就是不研究则不会关注到的有趣事情。
零宽字符顾名思义是没有宽度的字符，因此就很容易推断出这些字符在视觉上是不显示的。因此这些字符就可以作为不可见的占位内容，实现特殊的效果。例如可以实现信息隐藏，以此来实现水印的功能，以及加密的信息分享等等，某些小说站点会通过这种方式以及字形替换来追溯盗版。
而在富文本编辑器中，如果我们在开发者工具检查元素时，可能会发现一些类似于``即`U+200B`类似的字符，这就是常见的零宽字符。例如在飞书文档的编辑器中，我们通过`$("[data-enter]")`就可以检查到其中存在的零宽字符。
```html
\u200B
```
那么从名字上来看，这个零宽字符在视觉上是不显示的，因为其是零宽度。但是在编辑器中，这个字符却是很重要的。简单来说，我们需要这个字符来放置光标，以及做额外的显示效果。需要注意的是我们在这里指的是`ContentEditable`实现的编辑器，如果是自绘选区的编辑器则不一定需要这部分设计。
我们先来聊一下额外的显示效果，举个例子，我们在选择飞书文档文本内容，如果选中到文本末尾时，会发现末尾会额外多出形似`xxx|`的效果。在平时不关注的话可能会觉得这是编辑器默认行为，但是实际上这个效果无论是`slate`还是`quill`中都是不存在的。
实际上这个效果就是使用零宽字符来实现的，在行内容的末尾后面插入零宽字符，就可以做到末尾的文本选中效果。实际上这个效果在`word`中更常见，也就是额外渲染的回车符号。
```html
末尾零宽字符 Line 1
末尾零宽字符 Line 2
末尾纯文本 Line 1
末尾纯文本 Line 2
```
那么在这个零宽字符如果只是渲染效果的话，那么可能实际上起的作用并不很必要。但是在交互上这个效果却很有用，例如此时我们有`3`行文本，如果此时从第`1`行末尾选到第`2`行时，并且按下`Tab`键，那么此时这两行的内容就会缩进。
那么如果没有这个显示效果，此时进行缩进操作，用户可能认为仅仅是选中了第`2`行，但是实际上是选中了`1/2`两行文本。这样的话用户可能会以为是`BUG`，而我们也实际接受过这个交互效果的反馈。
```plain
123|
4|x56
```
也对各个在线文档实现进行了简单调研: 基于`contenteditable`实现的编辑器中，飞书文档、早期`EtherPad`存在这个交互实现；自绘选区的编辑器中，钉钉文档存在这个实现；`Canvas`引擎实现的编辑器中，腾讯文档、`Google Doc`存在这个实现。
在渲染效果部分，零宽字符还有一个重要的作用是撑起行内容。当我们的行内容为空时，此时这个行`DOM`结构的内容就是空，这就导致此行的高度塌陷为`0`，且无法放置光标。为了解决这个问题，我们可以选择在行内容中插入零宽字符，这样就可以撑起行内容且可以放置光标。当然使用`
```
在类似于`Notion`这种块结构的编辑器中，还有个比较重要的交互效果。即块级结构独立选择，例如我们可以直接将整个代码块独立选出来，而不是仅仅能选择其中的文本。这种效果在目前的开源编辑器很少有实现，都是需要自行以块结构重新组织设计选区。
通常来说，这个交互同样可以使用零宽字符来实现。因为我们的选区通常是需要放置在文本节点上的，因此我们很容易可以想到，可以在块结构所在行的末尾放置零宽字符，当选区在零宽字符上时就将整个块选中。这里用零宽字符而不是`
`，而在`FireFox(<60)`中的表现是会插入`
`。
- 在有文本的编辑器中，如果在文本中间插入回车例如`123|123`，在`Chrome`中的表现内容是`123123
`，而在`FireFox`中的表现则是会将内容格式化为`123
123
`。
- 同样在有文本的编辑器中，如果在文本中间插入回车后再删除回车，例如`123|123->123123`，在`Chrome`中的表现内容会恢复原本的`123123`，而在`FireFox`中的表现则是会变为`123123
`。
- 在同时存在两行文本的时候，如果同时选中两行内容再执行`("formatBlock", false, "P")`命令，在`Chrome`中的表现是会将两行内容包裹在同个``中，而在`FireFox`中的表现则是会将两行内容分别包裹`
`标签。
- ...
此外还有类似于实现加粗的功能，我们无法控制是使用`
```
那么通过`document.execCommand`来执行命令修改`HTML`的方案虽然简单，我们也聊过了其可控性很差。除了上述的`execCommand`命令执行兼容性问题之外，还有很多`DOM`上的需要兼容处理的行为，例如下面存在简单加粗格式的句子:
```md
123**456**789
```
有许多方式可以表达这样的内容，编辑器可以认为显示效果是等价的，此时可能也需要对此类`DOM`结构等同处理:
```html
123456 789
123456 789
123456 789
```
但是这里仅仅是视觉上相等，将其完整对应到`Model`上时，自然会是件麻烦的事。除此之外，选区的表达同样也是复杂的问题，以下面的`DOM`结构为例:
```html
123 456 789
```
如果我们要表达选区折叠在`4`这个字符左侧时，同样会出现多种表达可以实现这个位置，这实际上就会很依赖浏览器的默认行为:
```js
{ node: 123, offset: 3 }
{ node:
// A component is `contentEditable` and contains `children` managed by React. It is now your responsibility to guarantee that none of those nodes are unexpectedly modified or duplicated. This is probably not intentional.
```
这个`warning`的意思是，`React`无法保证`ContentEditable`中的`children`不会被意外修改或复制，这可能是不被意料到的。也就是说除了`React`本身是会需要执行`DOM`操作的，使用了`ContentEditable`之后，这个行为就变的不受控了，自然这个问题同样会出现在我们的编辑器中。
此外还有一些其他的行为，例如下面的例子中，我们无法从`123`字符选中到`456`上。也就是这里存在跨越`ContentEditable`节点了，就不能够正常使用浏览器的默认行为来处理，虽然这个处理是很合理的，但毕竟也会对我们实现`blocks`编辑器造成一些困扰。
```html
```
那么其实我们是可以避免使用`ContentEditable`的，设想一下即使我们没有实现编辑器，同样是可以选择页面上的文本内容的，就是我们普通的选区实现。那么如果借助原生的选区实现，然后在此基础上实现控制器层，就可以实现完全受控的编辑器。
但是这里存在一个很大的问题，就是内容的输入，因为不启用`ContentEditable`的话是无法出现光标的，自然也无法输入内容。而如果我们想唤醒内容输入，特别是需要唤醒`IME`输入法的话，浏览器给予的常规`API`就是借助`
## 参考
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-