ianstormtaylor
commented
7 years ago Hey @davolokh thank you so much for writing this up!
I'm definitely interested in figuring out the best way to make Slate collaboration-ready. I've been doing a bunch of research on OT/CRDT design to get the best solution. And if there's a way that the Slate core can remain unopinionated about OT vs. CRDT that would be awesome.
From all of my research it seems like OT is slightly more complex to implement, but is much more real-world-proven since it is what Google Docs, Dropbox Paper, etc. use to implement their collaborative editors. So I'm focusing on its needs first, which seem to overlap with CRDT a lot anyways.
It seems like what we need for the two is this:
- OT
- [x]
Transformneeds to be composed of smaller, simpler "operations". - [x] State changes need to expose the operations that occurred.
- [x] Operations need to be invertible, for undo history.
- [x]
- CRDT
- [x] All of the same needs as OT, plus...
- [ ]
Character-level unique keys. - [ ] A way to "tombstone" keyed objects.
(If anyone has additional requirements for either OT or CRDT that I need to add to that list and be aware of let me know!!)
Once we have those things, it seems like OT/CRDT can be implemented alongside Slate. But those things also aren't dependent on the core library changing much.
As for migrating it all to a Redux system, I'm slightly against it because it seems like a lot of overhead that makes Slate more confusing to people who aren't Redux-fluent, and it seems like it goes against how most React components are built. (For Hyperterm it actually makes a lot of sense, since they are essentially trying to make an entire app pluggable.)
I think that the current state can be changed to allow for "operations", by just exposing a single extra argument to onChange handlers. Taking us from the current:
function onChange(state) {
// apply the change locally by setting new `state` value
}To:
function onChange(state, change) {
// apply the change locally by setting new `state` value
// send the `change.operations` to the server
}Which is passed a transform argument which describes the transforms and operations that took place to change the state. (I'd actually like to rename this object from Transform to Change to make it more clear, and to remove the confusion with OT's definition for "transforms".)
And then the plugin handlers like onKeyDown or onPaste would simply return a Change object instead of an entirely new state, which is the equivalent of removing the .apply() call. Taking us from:
function onKeyDown(e, data, state, editor) {
// return a new `state` object by transforming the current one
return state
.transform()
.insertText('some new string')
.deleteForward()
.apply()
}To:
function onKeyDown(e, data, state, editor) {
// return a `change` object by running transforms on the current `state`
return state
.change()
.insertText('some new string')
.deleteForward()
}Let me know how that sounds! I'm still on vacation for a few more days, but hoping to get moving on this again next week.
Cc @SamyPesse too in case he has good thoughts, or in case I'm forgetting something obvious.
kommen
takashi
CooperSystems
ghost
kminehart
alanchrt
olivoil
trungtin
aslakhellesoy
akashkamboj
thomsbg
philcockfield
tvedtorama
TimYi
tobiasandersen
YurkaninRyan
geakstr
nornagon
lxcid
mshibl
oleksify
vshia
@yatskevich and me did a research and tried to design an appropriate architecture for supporting collaborative editing. There are some key points with explanation below.
The main idea is to implement a kind of Redux-like behavior within Slate.
<Editor store={Store} … />The goal of having Store is ability to have clear separation and understandable flow.UseCase:
This way allows us to have ability to manage operations in any suitable way (CRDT, OT, etc.) within Store.
Let’s see how to handle text paste operation in more details:
pasteTextdispatched to Store (data: {position, text}) No need to get current state, call transform() and return new state. Just dispatch an Action.CollaborativeStore:
pasteTextoperation into a set of atomicinsertCharacteroperationsSimpleStore:
In our mind such architecture allows Slate to be more flexible and extensible. But this is not a completely analyzed proposal - just an idea.
And a few pictures for clarification.
Workflow Chart:
Implementation example
pastTextin depth:P.S. Possibly, Store should send Transfroms (not Actions) to Server and get Transforms back.
@ianstormtaylor: Could you please take a look at this and share your opinion?