Collaborative Editable Voids

[Bartlett-Will]

First of all Thank you @BitPhinix for building out such a nice example. It has taken me some time to wrap my head around what is going on here.

I'm working on building something similar to Taskade where each "item" in a list would be an editable void with a forced layout. I'm expanding off your example and everything is working fine, but edits made to the nested editors are not collaborative or saved by the y-websocket server.

I'm thinking it is because the slate editors are being created without a corresponding Y.Doc, but the editable voids are being created in the same editor that has the corresponding y.doc.

Does anyone have any advice on how I could approach this issue?

[BitPhinix]

Hi @Bartlett-Will,

It's hard to give you specific advice for your implementation without knowing more details but the first thing I would try is to avoid nested editors to avoid the overhead of having multiple slate instances on the same page. While it isn't obvious in a lot of cases it is almost always doable and the better way to go.

If you can't avoid nested editors you could reference the nested doc by key and use a different shared type for it. E.g.

const doc = new Y.Doc();

// Main editor
const sharedType = doc.getArray<SyncElement>('content');
const yjsEditor = withYjs(editor, sharedType);

// Nested editor
const nestedEditorSharedType = doc.getArray<SyncElement>('nested-id'); // Referenced by key in the void block
const yjsEditor = withYjs(editor, nestedEditorSharedType);

Although you might need some custom cursor sync code in that case. Or you might want to create entirely different Yjs documents for your nested editors which would make it easier to reference the content of the nested editors in other documents.

Hope this helps, definitely let me know if something is unclear or you need help with anything else

[Bartlett-Will]

Thank you for the fast reply :) I would post a snippet but the codebase is large and I'm not sure how much help it would be without having to spend quite a bit of time on it. I'm just re-reading the slate docs for what feels like the 100th time, and I think I might be able to custom render elements that have a forced layout like this:

  switch (props.element.type) {
    case 'quote':
      return <QuoteElement {...props} />
    case 'link':
      return <LinkElement {...props} />
    default:
      return <DefaultElement {...props} />
  }
}, [])

Would I still have to create a different shared type for these elements as they would be react components? It is definitely not obvious to me, but this is my first $erious software project and I am still learning lots!

[BitPhinix]

Yeah, the slate docs definitely aren't enough to really get the grasp of everything and slate has quite a steep learning curve in the beginning as well. For me, it really helped to look through oss examples of plugins/editors (like this one).

The rendering logic/having different react components does not influence whether you need to use a different root shared type. It's depending on where your data for those components comes from. In your case, it seems like the components are getting their state/data from the slate state so you don't need to do anything special everything should be synced automatically (If you are using slates Transforms that is and aren't setting the data on the node directly).

[Bartlett-Will]

Here is a question that is not necessarily related. How does the sharedType get converted back into a slate document? I'm just trying to understand the whole process here.

[Bartlett-Will]

After trying to get the desired behaviour with a single editor, I think I need to have multiple. The reason being, I want to have a document that is created where users can't delete block elements from outside that element.

Would you need to create multiple providers? (one for each nested editor?)

[BitPhinix]

It doesn't sound that way, but it really depends on what you are trying to do. You can enforce the editor state via normalization and handle the user input side of things via making certain parts of the rendered element not contenteditable or preventing the deleting by overwriting even handlers.