Cursor decorator performance

[bjarkih]

Hi all, and thanks for great work on Slate Yjs!

I have a question around the performance of the cursor decorator provided by the sample useCursors implementation. When editing a document that another user is editing at the same time, we're updating the decorate function as the remote cursor positions change, which leads to frequent re-renderings of the Slate editor. For me, this leads to a visibly sluggish editor experience as soon as multiple users are editing the same part of the document tree.

Has anyone else encountered the same problem and, hopefully, found some solutions or workarounds? Any input appreciated!

Bjarki

[BitPhinix]

Hi @bjarkih,

Thanks for bringing this up. The current cursor implementation definitely could need some love 😅. I've been meaning to work on improving it for quite some time now but couldn't yet find the time to do so. I'll set aside a bit of time this weekend to write a better implementation.

[bjarkih]

No problem - thanks for everything you've done here so far @BitPhinix! I'll play around with this too on this end, and share here any learnings.

[BitPhinix]

👋 So sorry, didn't manage to fix it this weekend but started implementing the improvements mentioned here. I'll use this opportunity to also clean up the codebase quite a bit and rewrite the cursor plugin. You can track my progress here

[bjarkih]

Thanks @BitPhinix. Let me know if I can help - happy to contribute to the project!

[nemanja-tosic]

In our implementation, we do not update the decorate function, therefore we do not have frequent re-renders due to decorations. That being said, not sure what exactly you use for plugins, but i'll share our experience nonetheless.

TLDR we found that the problem is slate-react, rather than slate-yjs.

If the decorator function changes, the editor re-renders. We use a decorator function that pulls decorations from a WeakMap, so the decorator function is constant, and therefore not the reason for re-renders. Here's the catch though, provided you use slate-react: slate-react needs to invalidate the path to where the cursor is in order to update the cursor. To do so, we decorate all the nodes from the root to the selection like so:

const { decorate, cursors } = useCursors(editor);

decorations.set(editor, entry => {
  const memoInvalidationRanges = cursors
    .filter(function cursorsBelowEntry(cursor) {
      try {
        return Boolean(
          Editor.above(editor, {
            at: cursor,
            match: node => node === entry[0],
          }),
        );
      } catch (error) {
        return false;
      }
    })
    .flatMap(function memoInvalidator(cursor) {
      return [cursor];
    });

  return (
    decorate(entry) as Array<
      BaseRange & {
        isForward: boolean;
        isCaret: boolean;
        data: { name: string; alphaColor: string };
      }
    >
  )
    .map<CollaborationCursorDecoration & CaretProps>(range => ({
      ...range,
      name: range.data.name,
      alphaColor: range.data.alphaColor,
      isCollaboration: true,
    }))
    .concat(memoInvalidationRanges as any);
});

In other words, we decorate the selection, but also add memo invalidation decorations along the path.

[jasonm]

@bjarkih @nemanja-tosic Thanks for this discussion and sharing a solution! This looks very appealing. I'm fairly new to Slate and Yjs, and I don't quite follow where the decorations.set(...) call would be placed. Is that code a snippet from inside the implementation of a new Slate plugin that would be used instead of withCursor?

I've read through the slate-react plugins, and a few plugins from udecode/plate, but don't quite see how to put this together.

Could you share a few pointers, or elaborate a bit more? Thanks in advance for any notes!

[jasonm]

Hm, I think I understand... or am getting closer to understanding!

I am using React, slate-react, slate-yjs.

Here is what I did:

I declared the WeakMap outside of my editor component at the module level:

type Decorator = (e: NodeEntry) => Range[];
const decorations = new WeakMap<Editor, Decorator>();

I then removed the original useCursors call from my editor wrapper and replaced it with the above snippet from @nemanja-tosic :

// const { decorate } = useCursors(editor); 
// ...add snippet here...

Finally, I wrote the memoized decorator function that uses the WeakMap. The useCallback is inside my slate wrapper.

const memoizedDecorate = useCallback((entry) => decorations.get(editor)(entry), []);

and passed that into my slate-react Editable:

<Slate>
  <Editable
    ...
    decorate={memoizedDecorate}
    renderLeaf={renderLeaf}
  />
</Slate>

This often works very nicely! However, occasionally the position or ranges get out of sync. Here is Alice on the left and Bob on the right. Alice, in the left browser, has selection in the top "paragraph" (above the linebreak) and Bob, in the right browser, has the cursor at the end of the doc with no selection. But each selection seems drawn incorrectly for the other. This is after a fairly messy/active bout of typing, cut/pasting, etc.:

Do you all see consistent cursor/selection behavior, even under heavy editing?

[bjarkih]

Hey @jasonm - I'm sorry, but I completely missed this discussion! Are you still looking for feedback on the solution?

[jasonm]

Hi @bjarkih ! No worries. I have migrated over to ProseMirror / TipTap so I haven't thought about this too much. I can't say much about the relative performance as I haven't done any systematic comparison or benchmarking, but anecdotally I have not yet noticed it being an issue. Hope that's helpful!

[nemanja-tosic]

I've fixed this in slate (https://github.com/ianstormtaylor/slate/releases/tag/slate-react%400.74.2), so the change should no longer be needed.