Store paths instead of keys on selection data for `set_selection` operations

Do you want to request a feature or report a bug?

Feature.

What’s the current behavior?

Currently, set_selection operations store some selection details in the selection property, and other details in the properties property. selection is a Range, and only stores keys, not paths.

In order to support transforming selections against other operations, we need a way to store anchorPath and focusPath on Range – either instead of, or in addition to, the key.

Here’s what I’m trying to do with transformations:

1. Convert operation.selection into an plain JS object
2. Turn selection.anchorKey, selection.focusKey into anchorPath, focusPath
3. Merge properties with my plain JS selection object (because properties might only contain the difference from selection)
4. Transform my selection JS object against the incoming op
5. Transform properties against the incoming op
6. Turn the new anchorPath, focusPath on the selection object back into keys
7. Attach the transformed objects back onto the set_selection operation

The problem happens in Step 6. In Step 2, to turn the original anchor/focusKey into a path, I can use the document on operation.value. But in Step 6, those transformed anchor/focusPaths only apply to the new document.

This usually isn’t a problem – you can get the new state by Operation.applying the incoming operation to the selection op’s value. But the keys you get from that value are going to be different than the keys that eventually show up in the document, even though the paths will be the same. For example, if you call

value1 = Operation.apply(value, split_node_op)
value2 = Operation.apply(value, split_node_op)

the new node might have a different key in value1 and value2, even though it’s the same node in each document.

The only way I can think of to fix this would be to have Range allow you to use paths, and either allow you to also set key, or have key be a calculated property based on path and value.

What do you think? I’m happy to take a stab at a PR, if we agree on a direction.

What’s the expected behavior?

In a collaborative environment, keys can appear and disappear, but paths can be transformed and stay valid. In order to support both collaboration and undo / redo, set_selection needs to store both the old selection and the new selection as paths, instead of keys.

[ianstormtaylor]

@zhujinxuan I don’t think that experiment alone tells us that using paths isn’t a good solution. I think we’d be able to optimize it further, and we’d probably implement it slightly differently. And the “keys vs. paths” debate would affect many more code paths than just updating nodes, so we’d need to factor that in when talking performance. (If you weren’t suggesting that, my bad, feel free to ignore!)

[ianstormtaylor]

@justinweiss not totally sure I follow, but I would absolutely welcome a PR that changed to represent ranges with paths instead of keys, if that’s what you mean!