关于前端:PingCode-Wiki-协同编辑技术揭秘

作者：杨振兴

PingCode Wiki 于 2021 年 11 月 15 日正式上线了协同编辑能力。

PingCode Wiki 是从 2019 年 8 月份启动，到当初曾经两年多的工夫，协同编辑的上线标记着 PingCode Wiki 根本成熟。

接下来给大家介绍一下 PingCode Wiki 产品逻辑以及它背地的编辑器技术。内容分为四个大的局部，有产品局部的介绍，也有协同编辑技术局部的介绍：

一、PingCode Wiki 产品能力

二、富文本编辑器技术的演变

三、协同编辑技术的摸索

四、对知识库产品的思考

1. PingCode Wiki 产品能力

产品定位：

企业级知识库产品产品

研发赛道

1.1 常识生产能力

根底编辑能力

Markdown 快捷输出

其它

除了根底能力之外，还反对布局、日期、标签、提示框、代码块、附件等性能，对于内部数据粘贴反对辨认 Markdown、HTML（Excel、Word）。

1.2 常识流传能力

基于内容的沟通、分享也是企业知识库治理很重要的一部分，这块是 PingCode Wiki 的特色。

页面评论

实时告诉

告诉关上详情

实现基于内容高效沟通的闭环：评论 -> 告诉 -> 弹框详情 -> 回复

会话 & 提及成员

内容导出

目前反对导出 Word / PDF / Markdown 三种文件格式

页面共享

开启共享

查看共享

知识库共享

1.3 常识治理能力

• 一个一个知识库自身就是内容单元
• 层级页面树能够很好的组织内容
• 页面级权限管制

因为咱们是聚焦企业常识治理的，所以除了根底编辑体验、易于流传、内容组织咱们还关注到细粒度的权限管制，比方如何给对立组织下的非知识库成员共享内容，知识库内成员如何页面级权限等，这块咱们还在继续摸索中，页面级权限目前是反对团队共享。

首页入口

团队共享

解决团队内非知识库成员内容共享问题

其它

咱们也提供根底的页面复制、挪动、珍藏、模板等根底性能，企业常识治理是一个长久的话题，咱们还须要继续的改良。

1.4 多人协同编辑

11-15 刚刚上线的性能，欢送大家注册体验

协同编辑交互

![[杨振兴] 粘贴上传 – 2021-11-09 15_01 31.png](https://atlas-rc.pingcode.com…)

• 提供协作者列表、光标地位
• 反对抵触主动解决
• 反对主动版本历史
• 反对离线揭示
• 反对上线后内容主动同步

历史版本

目前是辨别长期版本和已公布版本，协同编辑过程中每隔 1 分钟会主动保留一个长期版本，这个靠近实时保留的长期版本是协同编辑内容的快照，一旦编辑的内容被协同者误删除 能够通过长期版本找回。

2. 编辑器技术的演变

从 2019 年开始做 Wiki 产品，咱们的富文本编辑器 大略经验了三个阶段：

• 旧版编辑器
• 新版编辑器
• theia 编辑器

特地想跟大家分享这外面的一些点，包含每个阶段的特点、局限性以及应用状况。

• 将来也要利用到 Wiki 产品中

2.1 新版编辑器

新版编辑器其实是在去年年初疫情期间开始正式启动的，那个时候旧版编辑器也就刚开始在 at 内测，问题也很多，然而因为新的基于 TS 的 Slate 的确足够有吸引力，所以促使咱们决定研发新版编辑器，这个 属于技术驱动。

2.2 Theia 编辑器

Theia 最后的指标是冲着开源去的，开源一个小型的编辑器，让 PingCode 其它产品能够应用，让 Angular 社区的也能够用。

目前 Theia 曾经利用到 PingCode 其它自产品中，然而代码还没有达到开源的水准，所以还须要继续迭代。

心愿 Theia 能够早日开源。

3. 协同编辑技术的摸索

3.1 技术选型

OT vs CRDTs

3.2 Yjs 计划

右边是富文本编辑层，左边是 Yjs 的框架层，两头时转换层，因为 Slate 编辑器框架的数据模型 和 Yjs 的数据结构是齐全不同的数据表白，所以中间层的作用就是相互转换他们的操作，保障 Slate 编辑器的数据结构和 Yjs 的数据结构能齐全放弃同步。

Yjs 计划流程图

Yjs Bindings-Slate 就是后面说的中间层，从流程图能够看出每一个客户端都会存储一个 Yjs ShareType 的数据结构正本，协同编辑中的音讯服务通信也是基于 Yjs ShareType 来进行的，相应的协同编辑的抵触解决也是由 Yjs 数据结构承当。

Yjs 架构劣势

3.3 技术影响产品性能

Yjs 因为是从数据结构层面解决协同编辑中的抵触的，比照 OT 它无疑是更持重的，并且对于简单的网络情况有很好的适应能力，大略个性如下：

4. 做知识库产品的思考

简略谈谈我对知识库产品的了解，总的来说我感觉做知识库产品还是挺艰巨的。

以下内容仅代表个人观点。

4.1 分类

最近几年文档类产品热度很高，面向企业服务的 Sass 产品我感觉外围分为三类：

1. 协同编辑
2. 脑图 / 绘图 /PPT/Excel
   | 对于共通点要求更高 |
   | 泛办公协同 | 飞书文档、钉钉文档 ||IM + 文档 + 智能 |
   | 垂直畛域办公协同 | 研发赛道：Confluence||Agile + Wiki + 生态 |

当然还有一些比拟有代表性的翻新产品比方 Notion、xxx

4.2 共通点

从我的角度看不同分类的产品的难点还是在共通点上：根底交互 、 稳定性，交互要尽量满足用户预期。

• 交互预期高

无论哪类产品对于编辑体验、稳定性的要求都是一样，交互满足用户预期是个大难题，一个是大家的交互习惯或多或少受过 Word 产品的影响，这么宏大的交互体系搬移到 Web 端产品是很难的。

• Web 编辑器技术壁垒

另外一个是 Web 端的编辑自身也已倒退了很多年，交互上也有很多翻新，编辑器技术尽管曾经失去很大倒退，但它仍然有一些技术壁垒，一个新的产品想要打入市场，研发工夫肯定是按年为单位的。

• PingCode Wiki

咱们 PingCode Wiki 从 19 年开始到当初大部分的工夫其实始终在打磨根底交互，保障内容编辑的稳定性及安全性。这也是直到往年下半年咱们才开始决定反对协同编辑的起因。而且我感觉现阶段咱们的一个重点依然是打磨根底交互，也就是 努力做到「交互满足用户预期」，冲破一些交互抵触，我举一些交互难解决的例子。

粘贴格局

咱们的编辑器通常会做粘贴辨认 Markdown、HTML 的格局，然而这两格局其实是有抵触，当用户进行粘贴时，粘贴板中 可能存在 Markdown 和 HTML 两种格局的数据，程序其实无奈精确判断用户实在用意：

• 我想辨认 Markdown 格局
• 我想辨认 HTML 格局

这个问题其实始终很困扰我，经常性的呈现处理结果不合乎我预期的状况。

解决方案：让用户抉择

Markdown & HTML 格局同时存在时，优先辨认 HTML 格局，提醒 Markdown 辨认转换。

ps: 灵感来源于语雀产品

Markdown 快捷输出

Markdown 快捷键输出当初曾经是各类产品的标配了，然而这类快捷输出语法其实有 可能跟用户实在输出的内容存在抵触，比方有序列表的语法：【1. + 空格】就很有可能呈现抵触：

• 用户仅仅想输出 1. + 空格，默认解决使用户掉入陷阱

我常常受这个问题的困扰，也发现咱们共事在写文档的时候经常出现短少空格的排版：

可能是深受快捷键的困扰。

目前咱们其实没有很好的解决计划，只是做了一些更严格的限定，以后节点是题目时不再辨认列表的快捷输出。

而后我最近在应用 flomo 产品的时候发现他们有一个交互解决的也还不错，【1. + 空格】自动识别成列表后，如果按【Backspace】键，能够回退到【1. + 空格】的状态，有一种忽然命中我预期的感觉。

这个就很细节了，富文本编辑器中像这样的交互门路有无数个，呈现抵触的中央也很多，这是所以产品须要独特摸索和解决的问题。

4.3 差别点

感觉不同状态的文档产品在性能上肯定是逐渐趋于异化的，只不过以后阶段各类产品的侧重点肯定是不同的，感觉我集体有点驾驭不了这个方向性的问题，所以只谈谈我对咱们所在的垂直研发赛道的一些了解：

• 继续打磨富文本内容编辑体验
• 深刻企业常识治理、研发场景
• 加强与 PingCode 产品矩阵的交融
• 逐渐裁减编辑能力，比方反对：流程图、脑图、甘特图等性能

这块有点干，所以贴一张 PingCode 产品矩阵图

从整体来看 Wiki 除了承当根底的常识积淀的能力，它还是 PingCode 其它产品的纽带，一些内容的输入、细节的沟通都是以 Wiki 页面内容为纽带，将来咱们还会思考通过利用市场的模式一提高裁减 Wiki 的内容生产能力。

4.4 翻新产品

集体认为 Notion 能够作为文档类产品翻新的一个代表，它扩大了文档的边界，可玩性很强。

另外一个是最近看到的国外的一个产品，提出了以文档为核心的办公协同 （Almanac），备受资本的推崇，变相阐明以后这个畛域大局依然未定，翻新的产品依然有很大的机会突出重围。

对于本文内容，咱们有一个线上的直播分享，大家有趣味能够理解一下。
https://www.bilibili.com/vide…

立刻体验 PingCode Wiki 的协同编辑