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 刚刚上线的功能，欢迎大家注册体验 ~
协同编辑交互
提供协作者列表、光标位置
支持冲突自动处理
支持自动版本历史
支持离线提醒
支持上线后内容自动同步
历史版本
目前是区分临时版本和已发布版本，协同编辑过程中每隔 1 分钟会自动保存一个临时版本，这个接近实时保存的临时版本是协同编辑内容的快照，一旦编辑的内容被协同者误删除可以通过临时版本找回。
2. 编辑器技术的演变
从 2019 年开始做 Wiki 产品，我们的富文本编辑器大概经历了三个阶段：
旧版编辑器
新版编辑器
theia 编辑器
特别想跟大家分享这里面的一些点，包括每个阶段的特点、局限性以及使用情况。
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 产品我感觉核心分为三类：
当然还有一些比较有代表性的创新产品比如 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），备受资本的推崇，变相说明当前这个领域大局仍然未定，创新的产品仍然有很大的机会突出重围。
关于本文内容，我们有一个线上的直播分享，大家有兴趣可以了解一下。
还未添加个人签名 2021.02.01 加入
还未添加个人简介
评论