就是常见的飞书文档钉钉文档那套东西,不过不用 OT ,用 CRDT 来实现协同,最近调研的社区最火的 yjs 。
但发现用 yjs 做版本恢复的话,要把所有的 update 都存下来,yjs 的 snapshot 存的只是 ydoc 某个时间点的版本坐标,没有数据,要想用 snapshot 还原版本,还得把之前所有的 update 存下来,初始化的时候全部取出来一个个 applyUpdate ,把本地的 ydoc 还原到之前最新的状态,之后才能用 snapshot 回溯到某个版本。
后端 websocket 网络层用了社区的 hocuspocus ,问题是每个字符的改变 onchange 方法里都会生成一个 update ,如果文档有几万字,就至少有几万个 update(还有段落啥的特殊字符),这样前端还原 ydoc 的时候这里接口都要返回几万条 update 数据前端一个个 applyUpdate 也太不合理了。像 OT 恢复版本取得是最近的一个快照和后面的 update 数据,问题 yjs 的快照只存的是坐标,想请教一下这块优化怎么处理的好?是不是 yjs 也定期 flush 一下把之前 update 手动合并一下?但 yjs 并没有相关的 api ,只能从结构上表面上合并成数组,返回给前端的数据条数上减少一点。
或者想听听各位对 yjs 做协同这块版本历史怎么实践的,网上这块资料基本为 0 。
1
scienhub 164 天前 via iPhone
请问你是基于什么考量决定用 yjs 呢? 前端编辑器用了什么呀?
我们也在实现类似的功能,可以交流一下 |
2
scienhub 164 天前 via iPhone
你有没有考虑用 git 做版本控制呢?
|
3
murmur 164 天前
别想了,老老实实买 wps 的文档中台,啥公司啊,都卷成黑海的地方还想着自研
office 文件支持做完了么,office 都支持不好还想着协同 |
4
Fca 164 天前
onlyoffice
|
11
unhappy224 91 天前
不用这样的, 关闭 GC 就行,就可以直接通过 snapshot 来恢复了,new Y.Doc( { gc: false} )。你这是一点他的论坛都没看啊
|
12
LawlietZ OP @unhappy224 这种方式我们也考虑到了,缺点是:关闭了服务侧的文档 gc ,文档数据会无限膨胀,就算富文本里可能只有 1 个字符,用户在反复编辑这一个字符。经典的 crdt 数据膨胀问题。当然也有办法去优化
|