react grpc_从零开始使用React，Golang和GRPC构建协作代码编辑器

react grpc

For a better reading experience, view this on the original site.

为了获得更好的阅读体验，请在原始网站上查看。

I’ve been learning Golang and one of things I love so much about it is the fact that they have this.

我一直在学习Golang，而我最喜欢的一件事就是他们有这个。

This is especially useful when you’re halfway in a project and want to test something out but don’t want to go through the trouble of setting up another work directory for a small little test.

当您在项目的中途并且想要测试某些东西但又不想为另一个小的测试而设置另一个工作目录的麻烦时，这特别有用。

I’m also on that Leetcode Grind so this has been serving as my personal bug catcher. Also, I always thought it was kinda cool that companies would make use of collaborative code editing websites to conduct their interviews.

我也在Leetcode Grind上，所以它一直是我的个人错误捕捉器。 另外，我一直认为公司利用协作代码编辑网站进行采访是很酷的。

So I thought, why not try to make my own?

所以我想，为什么不尝试自己做？

问题 (Problem)

I started off giving myself some time to brainstorm for a solution and some of the things I came up with are as follows:

我开始给自己一些时间集思广益以寻求解决方案，我想到的一些事情如下：

1.在每次按键时发送整个文档 (1. Send the whole document on every keypress)

So obviously this wasn’t going to be my best idea but I’m not sure why I thought it would work under certain circumstances. The most obvious problem would be network delays causing each user to overwrite the other. Also, the amount of data to send over the network would begin to ramp up as the document gets bigger.

因此，显然这不是我的最佳主意，但是我不确定为什么我认为在某些情况下它会起作用。 最明显的问题是网络延迟，导致每个用户覆盖另一个用户。 另外，随着文档的增大，通过网络发送的数据量将开始增加。

2.发送信件以及插入位置 (2. Send the letter along with the position to insert)

This would fail since the positions change on every insert and the documents would get out of sync really quickly. This got me to the next one which I almost thought I had it.

这将失败，因为每个插入位置的位置都会发生变化，并且文档将很快变得不同步。 这使我进入了下一个我几乎以为自己拥有的地方。

3.按行分割文档，并按行插入 (3. Split the document by lines and handle inserts per line)

I honestly thought this would work albeit being very hard to implement UI-wise since I would have to account for different line inputs and displaying the text. I also quickly realise that I shifted my problem from character positions in #2 to line positions in this one.

老实说，尽管很难在UI上实现，但我必须这样做，因为我必须考虑到不同的行输入和显示文本。 我也很快意识到我将问题从＃2的字符位置转移到了这一位置的行位置。

4.为每个字符附加一个唯一的递增计数器 (4. Attach a unique increasing counter for each character)

Looking back, this was probably my closest idea. I thought of either linearly increasing the counter by a certain factor to account for minor edits in the middle but I wasn’t really sure how I would handle cases where the difference in count was less than 1 (e.g. inserting between counts 1 and 2). If I could do this however, it was just a matter of sorting and inserting at the right locations.

回顾过去，这可能是我最接近的想法。 我考虑过将计数器线性增加某个因子以解决中间的少量修改，但我不确定如何处理计数差小于1的情况(例如在计数1和2之间插入) 。 但是，如果我能够做到这一点，那只是在正确的位置进行排序和插入的问题。

I wasn’t exactly working on this the whole time I was awake so at this point it was already a couple of days in and I decided to just Google it.

我整个清醒时都没有真正在做这项工作，所以到现在为止已经有几天了，所以我决定只使用Google。

解 (Solution)

I came across two ways collaborative text editing could be achieved.

我遇到了两种可以实现协作文本编辑的方式。

1. Operational Transforms (OT)
   运算转换(OT)
2. Conflict-free Replicated Data Type (CRDT)
   无冲突复制数据类型(CRDT)

I’m no expert so to give a very very very high-level overview:

我不是专家，所以给一个非常非常高层次的概述：

OT works by changing the remote operation before applying it on the local document. This method is, in a sense, more algorithmic to determine what change must be applied to the received operation before executing it. I haven’t read up much about this because I chose to go for the latter.

OT通过在将远程操作应用于本地文档之前更改远程操作来工作。 从某种意义上说，这种方法更具算法性，可以确定在执行接收到的操作之前必须对其进行哪些更改。 我还没有读过很多，因为我选择了后者。

CRDTs are just data structures that can be modified locally and have these updates propagated remotely without any conflict. There are many types of CRDTs and the one I chose to implement is the LSEQ (or at least my jumbled version of it). The final implementation mentioned in the paper is CRATE which is LSEQSplit, an extension of LSEQ. Their implementation can also be found here.

CRDT只是可以在本地修改的数据结构，并且可以将这些更新远程传播而没有任何冲突。 CRDT的类型很多，我选择实现的一种是LSEQ(或者至少是我的混杂版本)。 在论文中提到的最终实现是CRATE是LSEQSplit，LSEQ的延伸。 它们的实现也可以在这里找到。

序列 (LSEQ)

I’m not even going to pretend to fully understand the motivations and improvements of LSEQ compared to other CRDTs but I’m guessing it has something to do scalability of the size of identifiers allocated to each update. If you do want to know more, read the paper I linked to down below.

与其他CRDT相比，我什至不假装完全理解LSEQ的动机和改进，但我猜想它与分配给每个更新的标识符大小具有可伸缩性。 如果您想了解更多信息，请阅读下面链接到我的论文 。

The general idea behind this is issuing a unique identifier to each character that you add in order to resolve conflicts in concurrent editing. This is done with the following elements.

其背后的总体思路是为您添加的每个字符提供唯一的标识符，以解决并发编辑中的冲突。 这是通过以下元素完成的。

Path

路径

The path is just a number indicating where the character should be. A character with a higher path will come after a character with a lower path.

路径只是一个数字，指示字符应该在哪里。 具有较高路径的字符将位于具有较低路径的字符之后。

Site

现场

The site is the unique value attached to each user, this will help to resolve conflicts when two paths are the same.

该站点是附加给每个用户的唯一值，当两个路径相同时，这将有助于解决冲突。

Cou