make `operation.newPath` consistent

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

Improvement.

What’s the current behavior?

Right now there are two properties involved in a move_node operation: the path and the newPath. The path makes sense, since it refers to the node in the current document.

But the newPath is confusing, because it currently refers to the new location of the node, but in respect to the current (old) document. This is usually fine, but gets tricky in cases of siblings. For example, given a document of:

<document>
  <paragraph key="a">
    one
  </paragraph>
  <quote key="b">
    <paragraph>two</paragraph>
  </quote>
</document>

To arrive at:

<document>
  <quote>
    <paragraph>two</paragraph>
    <paragraph>one</paragraph>
  </quote>
</document>

You use an operation of:

{
  type: 'move_node',
  path: [0],
  newPath: [1, 1],
}

Where [1, 1] refers to the location the node would be move to relative to the current document, but without removing the node from its original location. However, when you look at the end state, you’ll notice that the node doesn’t end up at [1, 1], but at [0, 1] on account of removing it earlier in the document and shifting everything backward one space.

This seems confusing?

What’s the expected behavior?

Change the newPath to refer to the location in the document after the original node has been removed, so that it always ends up where newPath says it will be?

EDIT: Based on the conversation below, we should go with “before the original node has been removed” always instead.

[justinweiss]

I think this is true sometimes, but not all the time.

This might have changed, but when I last worked on this, moving a node under the same parent would act as if you had removed the node first, but other moves would act as if you hadn’t. For example: move_node with path: [2] and newPath: [4], the node would end up in position [4] in the new document, not position [3]. Moves to new parents worked the way you described.

I don’t mind using either the new tree or the old tree, but I think all moves should be consistent. For what it’s worth, I wrote a helper function to rewrite all the moves to use old-tree-positions, because I found them easier to think about.

[bryanph]

EDIT: Based on the conversation below, we should go with “before the original node has been removed” always instead.

@ianstormtaylor isn’t this already the case? 🤔

edit: i just reread justin’s comment: so the inconsistent case is the case where the node is moved in the same “path level” (how do you call this 😅 )?