有做过在线文档协同办公的老哥吗，进来交流一下技术相关(Y.js 相关)

[LawlietZ]

就是常见的飞书文档钉钉文档那套东西，不过不用 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 。

[scienhub]

请问你是基于什么考量决定用 yjs 呢？ 前端编辑器用了什么呀？
我们也在实现类似的功能，可以交流一下

[scienhub]

你有没有考虑用 git 做版本控制呢？

[murmur]

别想了，老老实实买 wps 的文档中台，啥公司啊，都卷成黑海的地方还想着自研

office 文件支持做完了么，office 都支持不好还想着协同

[Fca]

onlyoffice

[LawlietZ]

@murmur 不用支持 office

[LawlietZ]

@murmur 这个贴只用来交流技术 其他的考虑就不用你操心了谢谢哈

[LawlietZ]

@scienhub git 做版本也要考虑存储那套，但协同版本这块没见过用 git 做控制的

[scienhub]

@LawlietZ 不知道你最后存的是不是文本文档。我们最终存的是文本文档，因此选择用 git 做版本控制了。

[LawlietZ]

@scienhub 存全量文本，如果你要做协同，这种数据是笛卡尔积式增加的，对存储和 IO 很不友好

[LawlietZ]

@scienhub 可以加 vx emhhbmcxMTA0MjcyMzE5 交流一下

[unhappy224]

不用这样的， 关闭 GC 就行，就可以直接通过 snapshot 来恢复了，new Y.Doc( { gc: false} )。你这是一点他的论坛都没看啊

[LawlietZ]

@unhappy224 这种方式我们也考虑到了，缺点是：关闭了服务侧的文档 gc ，文档数据会无限膨胀，就算富文本里可能只有 1 个字符，用户在反复编辑这一个字符。经典的 crdt 数据膨胀问题。当然也有办法去优化