How to modify deltas before document is updated?

[smasher164]

Similar to this issue in QuillJS: slab/quill#2558, how can I modify the deltas that will be inserted into the Document, before it happens? Right now, I'm listening for changes from the controller

var _controller = quill.QuillController(
    document: notes.list[position.position],
    selection: const TextSelection.collapsed(offset: 0),
);
_controller.changes.listen((ev) {
      notes.notifyListeners();
});

But I'd like to make a CRDT the source of truth for the document. So every delta would be inserted into the CRDT, and changes in the CRDT would be reflected in the Document. However currently, the Document is changed no matter what. Is there a way to overcome this? Something like a disableUpdates flag?

var _controller = quill.QuillController(
    document: notes.list[position.position],
    selection: const TextSelection.collapsed(offset: 0),
    disableUpdates: true,
);
_controller.changes.listen((ev) {
      crdt.insert(ev);
})
// ...somewhere inside the crdt provider...
class CRDT with ChangeNotifier {
// ...
    void insert(ev) {
        // ...
        document.update(...)
        // notify listeners on document changes
    }
// ...
}

[kairan77]

From what you describe, you would be effectively using a ChangeNotifier to monitor keystroke changes and fire off events upon each keystroke, this could easily sends off dozens of events every second. Maybe you have a special use case and this is just my opinion: You really do not want to do this.

WYSIWYG editor means "What You See is What You Get" to the end users, the editor should be the single source of truth, so leave the editor alone during the editing session, and only hands of the edited data back to your ChangeNotifier upon finish editing

[your session before editor is active] -------(your CRDT sends current value to editor Once)--------> [editor session] ----------（your editor update your CRDT once upon finishing）----------> [your session]

[smasher164]

Even currently, the Document rendered in the editor is the source of truth, is it not? My idea is to just put a CRDT between the editor and the Document. It wouldn't be a major blocking operation, just updating a data structure with the Deltas provided by the editor, and building a Document out of that. The only difference is that the CRDT maintains precise information about when an edit happened. This is useful for merging changes accurately with other peers. Right now, calling Document.toDelta just returns an insert with its entire contents. So treating that as the value to update the CRDT will lead to a poor editing experience.

[kairan77]

I see where you are going now, and the use case makes sense, but would be extremely difficult to implement correctly.

passive monitoring is ok

passive monitoring + active intervention != passive monitoring

these tools naturally do not fit with active intervention/server-side-render-decision-making.

Your use case is formally equivalent to the following simplified use case requirement:

• suppose you have the following usage rule in your editor: User can type AAA into the editor, but AAAA is not allowed

now after user enter 3As, and upon the 4th Keystroke, nothing happened, this would be a bit counter-intuitive in a WYSWYG editor, isn't it?

that nothing also has a cost, this is just one of the millions of intervention scenarios you have to implement manually no matter what scaffolding had been provided with the underlying toolset, how would you go about intervening correctly and provide meaningful response for ease case?

Look at how github, ckeditor, or Microsoft sharepoint work, these tools would NOT disable a user's work in real-time during their own editing session because a 'potential merge conflict' emerged due to other peer's concurrent edits. Merge always come later so no real time intervention is needed, just monitoring and logging.

I been through the same hoop many years ago with web2 techs, and came to the conclusion this would be quite impossible to implement.

However if you insist on going down this road, you can experiment and see how it goes.

declare your own ValueNotifier editorDisabled,

wrap your editor inside the ValueListenableBuilder, with the editable flag based on the current value of editorDisabled

then

_controller.changes.listen((ev) {
crdt.insert(ev);
editorDisabled.value = true/false; //base on your intervention logic
});

of course you would have to maintain your own state preemptively about when to toggle that value.

[smasher164]

What you are saying makes a lot of sense. I re-thought the architecture a bit, and instead of doing

user makes edit─────►CRDT─────►Document─────►Rendered View
                     │ ▲
                     │ │
                     │ │periodic sync
                     │ │
                     ▼ │
             Database & Peers

I can instead do

user makes edit─────►Document─────►Rendered View
                      │  ▲
               instant│  │instant
                      │  │
                      ▼  │
                      CRDT
                      │  ▲
                      │  │
              periodic│  │periodic
                      ▼  │
               Database & Peers

The CRDT, database, and networking logic will be living on a separate thread. I'll be broadcasting deltas over there so it can maintain its own version of the Document with changes/timestamps. This thread can feel free to talk to the network/db without affecting the editor flow. Occasionally, when a merge comes in, we can send them over as deltas for the UI thread to update the Document.