Canvas-Editor 在线文档协同实现方案（YJS）

原创已于 2026-03-05 16:00:26 修改 · 1.8k 阅读

17 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#word #编辑器

于 2024-12-11 09:07:04 首次发布

最近快秃头了，项目要搞个Word协同的，原先的页面Word在线文档使用的是富文本tinymce，说实话这个和在线文档还是很有差距的，主要是Word的排版太变态了，Word文档本身有很多历史沉淀的屎山一样的业务，html+css是基本上只能覆盖一部分的Word排版，想要完美的或者能对外吹得起来的效果图，还是得上Canvas或者svg；可怜我还是熬夜加班去收集解决方案和思路。

以下说下我收集到的一些在线文档的信息：

毫无疑问，如果对于单个或者公司自用的（非商用、非商用、非商用）,Onlyoffice的社区版是最完美的，什么都不用说，直接按流程搭环境上了了事。当我发现这个时，我感觉我又能很愉快地轻松度过的，结果，公司法务很明确告诉俺，NOT，NOT，NOT。当然，Onlyoffice也有商用版。

其他的如腾讯文档、WPS在线文档、tinymce协同等等，基本上这么说，要商用，得花钱，现在这个环境，地主家也没余粮，而且以上几个价格都黑（我个人觉得）。

一、在线编辑器选型

所以，当我在网上找个这个时，我感觉我又能了，这个是目前网络上对Word支持（主要是排版）的开源中最好的，没有之一；并且从代码上看，这个明显是有投入实际使用的，对此，我在此对作者表示万分感激！（知乎这边不能上表情，差评），先上官方资源，以表谢意。

canvas-editor | rich text editor by canvas/svgrich text editor by canvas/svg

https://hufe.club/canvas-editor-docs/

https://hufe.club/canvas-editor/

二、协同方案和协同组件(YJS)

本来我想简单的对编辑中的增量做处理就好，反正说实话，这个功能也是对外的宣传口，用来钓鱼的；后面看到YJS，一番了解，惊为天人呀，去中心化的协同算法(这里说下，它的核心是数据一致性，里面的文本YText协同可以是非常成熟的OT算法，大家可以放心使用，无论高低版本，不大可能改动这块算法)，具体的OT和CRDT等概念和信息，就不多说了。

1、YText

YJS的可共享类型，主要的结构是这样的，大家请看，核心是其中的0 和'bold text'

ytext.insert(0, 'bold text', { bold: true })

2、YMap

YJS的可共享类型，主要就是Set、Get和Delete

以上详情请自行到Yjs的官方文档去查询，这个给大家一个中文文档参考下

https://chinabigpan.github.io/yjs-docs-zh-cn/routes/API.html#y-map

三、编辑器降级为Vue2.0

OK，材料都搞来了，准备开始做饭了，遇到的问题也得一点点出来了。

Canvas-Editor 源码只有typescript版本，没有纯血版的js版本，因为对这个文档要求不仅仅只有文档的编辑，还涉及其他相关的业务组件的处理，我们的项目源码是Vue2.0，咳咳，看到这个大家都应该了解我们这个项目比较远古的，所以不能直接食用，虽然我早就想把Vue2.0升级为Vue3，然后直接使用typescript，但打开代码一看密密麻麻的业务，算了，命只有一条。

所以，辛辛苦苦的把Canvas-Editor 降级为Vue2.0；途中遇到不少的语法问题，这就不一一复诉了，反正我是去了半条命。

四、Yjs版本也只能使用较低版本

Yjs版本也只能使用较低版本，不过也够用了，毕竟看最新的升级文档，并没有对 YText这块有变动，我们最核心使用的就是这块。即使使用这个低版本，js中也有部分语法要修改才能在Vue2上运行。

五、编辑器的协同适配

1、编辑器内容监听

Yjs的文本原生支持的为Delta数据结构（具体可参考它和Quill的Demo代码），而Canvas-Editor编辑器初步看存储结构貌似不行，得挂，难道我这几天都白忙活了吗；还好，详细阅读了Canvas-Editor编辑器源码或实际跑下代码你就能发现，原来，Canvas-Editor编辑器从核心底层就支持协同这种处理(非树状数据结构，而是数组结构)。

文档存储数据较为精简，例如输入123，存储结构如下

   {"header":[],"main":[{"value":" 123"}],"footer":[]}

实际运行中，实际的元素结构如下：

各位，发现没有，运行中的元素结构是整个文档的最底层基础，也是不可再细分的单位，整个文档的编辑、文字、分页、图片、控件等核心功能都是基于这个实体去扩充。

各位，这样一看就很明了，只要针对这个运行元素列表去监听，就能完美的满足Yjs中的Ytext运行机制。

然后，在此得还是得感激下Canvas-Editor的作者，他涉及的所有的操作导致的界面变更（运行元素列表）都是底层核心的一个统一的方法，Draw.js中的spliceElementList，监听下这个变动，基本上就完成8成以上的编辑器修改的代码了

2、编辑器输出协同数据到外部

注意下deltas的retain数据，这个必须符合YText规则

3、编辑器接受其他协同数据

六、YJS的协同适配

1、YjsWebsocketProvider

直接下载y-quill中的WebsocketProvider改改就行（去除掉Quill的相关）

2、YjsEditorProvider

3、YjsUserProvider

当前文档的协同用户列表（含光标信息）的共享维护（走YMap）。光标的监听走编辑器的rangeStyleChange监听。

七、协同的运行效果

1、增量效果

增量的比较简单，无非是细磨的功夫，主要是数据格式要走Yjs的delta，界面初始数据123456，输入7，接受到的增量数据。

2、核心效果

当一个文档被N个用户操作后（增删改）一大堆后，新用户打开这个文档时，他接受到的数据是这样的，全部是新增的数据，无删除和更新的数据。

八、总结

1、由于环境原因，无法把代码直接发出来跑一波

2、这个代码是初版演示的，写得还是很粗糙，但思路大家可以借鉴下

3、上面的改动增对原编辑器都是新增的代码，协同这块还是得他编辑器源码中去改会好些，很多数据仅能在编辑器中获取，否则得去加各种command.api来外部适配。

代码受环境影响，只能是截图了，源码搞不出来外面。

各位，有空的话顺手帮忙注册下，年底KPI了~谢谢各位~