Experimental move feature

[dmonad]

_{Huly®: YJS-433}

[zxch3n]

Furthermore, it should be possible to move content to another shared type. This can be helpful when you want to move a type from one Y.Array to another.

🤯 Does this mean it will be able to resolve the parent-children loop?

For example, original content is

[
    {
      id: "A",
      children: [],
    },
    {
      id: "B",
      children: [],
    }
]

user0 and user1 concurrently move the content. user0 moved A inside B

[{
  id: "B",
  children: [
    {
      id: "A",
      children: [],
    },
  ]
}]

and user1 moved B inside A

[{
  id: "A",
  children: [
    {
      id: "B",
      children: [],
    },
  ]
}]

[dmonad]

• [ ] TODO: don't encode relativePositions using toUint8Array
• [ ]

[dmonad]

@zxch3n This is not in the scope of this PR. But eventually, I'd like to implement this. I believe there is a valid approach to resolve circles with a reasonable performance tradeoff. A similar cyclic problem occurs in this PR when moving ranges inside moved ranges. I.e. assume "abcd". Move "ab" between "cd", and concurrently move "cd" between "ab". I'm resolving this issue using circle detection as well.

In this PR, I'm only going to implement moving ranges of content in Y.Array. This will eventually be extended to Y.Text. Then we are going to look into moving across types. However, that is not a priority for me right now.

[marbemac]

Hi Kevin, very exciting that "move" is on your radar! I understand you're focused on moving ranges within a Y.Array in this PR - is re-parenting ala https://discuss.yjs.dev/t/moving-elements-in-lists/92/14 in the realm of possibility at some point (I know, nobody likes dates, just in general :)).

[dmonad]

Hi @marbemac,

That's a huge one.. It is definitely not in scope for the initial release. Eventually, yes, I'd like to support that. However, I feel there are more important things to work on right now, so I can't give a timeline.