Open situ2001 opened 2 years ago
当然对于上述的场景,我们还可以深入一步,直接提供协同模式下的FileProvider
(比如一般的纯web IDE会提供HTTPFileProvider
),定义协同状态的文件的读取、新建、打开、保存、删除等的具体操作。
Update:跳过这里,看下面的comments
这里有一个假设。假设YDoc存到了某处(某处可以是IDE的Node端),需要加载与更新。
仅支持了 IDE 编辑器部分的协同编辑功能
暂时仅支持在编辑器编辑文件,未处理外部对 IDE 工作区文件的修改(如 git pull, 用其他软件修改了文件内容) #19
未支持 browser-only 与 electron 平台(优先级可以降低),理论上,提供协同模式下的FileProvider
(比如一般的纯web IDE会提供HTTPFileProvider
)也能解决问题
在TextModel与CRDT绑定前(事件EditorDocumentModelCreationEvent
发生在EditorDocumentModel
创建完成后,而该绑定发生在EditorDocumentModelCreationEvent
的handler里,且异步),如果发生了修改(再比如用户迫不及待,还没绑定成功,就开始进行编辑了),将不会生效(绑定后的TextModel文本应为CRDT的文本),甚至容易💥。常发生在跨文件重构的场景下(如F2重命名变量),未试过,不确定是否有问题。我在下面的comment提出了一种可能的解决方法
对于上面的问题,为了能有更好的体验,我想可以按这样继续设计下去
由于目前只协同了文本编辑部分,因此决定Y.Map装着工作区的所有文件的文本(后期可以逐渐迁移到subdoc)。文件的作用仅仅只是用来获取文件信息,以及存储着某一时刻Y.Text.toString()
的内容(外部软件可以操作这个文件,具有兼容性。外部发生的变化通过 #19 的方法给apply到Y.Text里头就行了)
记得把CRDT给持久化(目前只是in-memory。。)
根据目前对框架的大体理解,可以试着像下图这么做,加粗部分为暑假实现的部分。
暑假的实现是把协同编辑的功能的加载给套到不同事件上(设想给人穿外套:监听事件EditorDocumentModelCreationEvent
,事件发生后(此时DocModel已经创建好了)才开始异步进行绑定CRDT等操作,绑后将CRDT的文字给覆盖到TextModel上)。
TextModel与CRDT的绑定最好是在DocModel创建的时候,而不是在DocModel创建后进行绑定。因此下图,很有可能还要加上自己定义的IEditorDocumentModel
如果要有更好的体验,应该把下面的provider都实现一遍。
模块目前是用到了Websocket进行网络通讯,Y.Doc暂存到了node server内存上。目前来看,y-websocket提供的是网络通讯能力,暂存在内存相当于一种持久化。把这两件事抽离出来,得到两个问题如何进行网络通信如何持久化存储Y.Doc因此,可以假设,用户可以通过贡献点机制,往CollaborationContribution
中添加下面方法的具体实现从而使得模块变得更加灵活。2022/08/28 Update
见下面的comments,个人理解是先解决好协同状态下,文件以及DocModel的打开删除等操作过程,让这个模块更好地融入到该IDE框架。