Open situ2001 opened 2 years ago
Tl; DR 把Node也当成协作者就行了。
直到快结束的时候才想到一个问题:当前的假想是用户会直接使用IDE的编辑器对文件进行编辑,而没有考虑到文件在文件系统发生的改变(比如git merge有可能会改变文件)。
git merge
如果是以CRDT为中心(在此情景下,在磁盘上的文本文件的作用,仅仅是保存文本)的话,不妨可以假设:文件在文件系统出现了改变,可以等价为用户在编辑器编辑产生的改变(yjs Delta,查阅文档得知格式),用户的输入最终会变为一个一个的Delta,作为Yjs的CRDT的changes。
那么,为什么不把文件系统发生的改变也给归进来呢?关键就是,如果文件在文件系统中的改变,也可以转化为yjs能认的Delta就好了。
这里的想法是将文本文件发生的改变给通过jsdiff得出diff,然后转换到yjs的Delta format,最后merge到Y.Text中,使用ytext.applyDelta(delta: Delta)
jsdiff
ytext.applyDelta(delta: Delta)
那么,crux如下:
diff
并且,IDE前端有不少更新TextModel的情况,如果有n个client,那么就会出现n份更新...
举个例子,比如:监听到文件系统的外部更新,每一个client都会调用一次这个方法。
https://github.com/situ2001/opensumi-core/blob/24f19792ad57af646b7cbc47d6990c2ad45a0de5/packages/editor/src/browser/doc-model/editor-document-model-service.ts#L183-L209
不过,对于上述问题,专门为协同状态下的IDE实现IEditorDocumentModelContentProvider就行了
IEditorDocumentModelContentProvider
Tl; DR 把Node也当成协作者就行了。
直到快结束的时候才想到一个问题:当前的假想是用户会直接使用IDE的编辑器对文件进行编辑,而没有考虑到文件在文件系统发生的改变(比如
git merge
有可能会改变文件)。如果是以CRDT为中心(在此情景下,在磁盘上的文本文件的作用,仅仅是保存文本)的话,不妨可以假设:文件在文件系统出现了改变,可以等价为用户在编辑器编辑产生的改变(yjs Delta,查阅文档得知格式),用户的输入最终会变为一个一个的Delta,作为Yjs的CRDT的changes。
那么,为什么不把文件系统发生的改变也给归进来呢?关键就是,如果文件在文件系统中的改变,也可以转化为yjs能认的Delta就好了。
这里的想法是将文本文件发生的改变给通过
jsdiff
得出diff,然后转换到yjs的Delta format,最后merge到Y.Text中,使用ytext.applyDelta(delta: Delta)
那么,crux如下:
diff
处理后apply到Y.Text中?