Slate: Implicit Leave operations not "lowest-level" and granular enough for collaborative-editing

[DanweDE]

The slate operations docs say:

An operation is the lowest-level description of a specific change to a part of Slate's value. They are designed to be collaborative-editing friendly.

Currently I see one issue with your operation description on the "leaf" level.

Assume three leaves, one of them with a bold/italic mark:

This _is_ text

and assume the user removes the mark so it becomes

This is text

Slate.js gives you only a remove_mark operation for this. The merging of those three nodes into one happens implicitly, there is no merge_leaf operation.

The "lowest-level description" I'd expect here would be

1. remove_mark on the leaf with index 1
2. merge_leaf with index 1 and 2
3. merge_leaf with index 0 and 1

Same goes for the reverse case where adding a mark results in add_mark but not in split_leaf.

[DanweDE]

Is there any reason why those operations do not already exist or does this sound like a reasonable improvement?

[ianstormtaylor]

Why do you need leaf-level information? That is implicit in adding/removing marks and shouldn’t be necessary for implementing OT I don’t think.

[DanweDE]

Maybe OT is a bad argument, whether you really need the mentioned leaf-level information might depend on the OT type – I was thinking about transforming json instead of using an OT type that is actually aware of marks.

That is implicit in adding/removing marks

You could make the same argument about e.g. breaking a paragraph which triggers two split_node, one on the Text level, one on the Block level while only the one on the Text level would suffice as it already implies the split on the Block level. Yet, there are two operations triggered.

So I think it would be consistent and there should be an explicit operation triggered for each “_specific change to a part of Slate's value_” as the documentation states.

[ianstormtaylor]

You could make the same argument about e.g. breaking a paragraph which triggers two split_node, one on the Text level, one on the Block level while only the one on the Text level would suffice as it already implies the split on the Block level. Yet, there are two operations triggered.

Not exactly, since splits can occur up to a certain height in the three, but not necessarily always to the top. So you either need to encode a height in each text-level split, or use multiple split_node operations. But without changes, dropping the block-level split_node operations would be losing information.