fix(nodeUtil): moved blocks now included in the editor changes #1931
Conversation
|
@rmolinamir is attempting to deploy a commit to the TypeCell Team on Vercel. A member of the Team first needs to authorize it. |
| handleDrop: (_view, _event, slice) => { | ||
| const draggedBlock = nodeToBlock( | ||
| slice.content.child(0), | ||
| editor.pmSchema, | ||
| ); | ||
| this.draggedBlockId = draggedBlock.id; | ||
| return false; | ||
| }, | ||
| }, | ||
| filterTransaction: (tr) => { | ||
| if (tr.getMeta("uiEvent") === "drop" && this.draggedBlockId) { | ||
| tr.setMeta("draggedBlockId", this.draggedBlockId); | ||
| this.draggedBlockId = undefined; | ||
| } | ||
| return true; | ||
| }, |
There was a problem hiding this comment.
Ended up attaching the draggedBlockId to the transaction, I'm unsure if this is the ideal approach though 😅
Screen.Recording.2025-08-10.at.12.50.38.AM.mp4
There was a problem hiding this comment.
No, I don't think this is the right approach. What should happen here is using the order of the blocks only, derive which block has actually moved
There was a problem hiding this comment.
That's what I meant here. It's not possible with just indexes.
Say you have an editor with these values: [1,2,3]. If you drag 2 to the first slot, you end up with [2,1,3], but the user could also have dragged 1 into the second slot ending up with [2,1,3], this is why it's impossible to do it with indexes alone. Knowing which block was dragged is necessary if you want to filter the rest of the blocks.
There was a problem hiding this comment.
Hm, yea. This is a good argument for over reporting on all of the indexes that have changed.
I don't want for dragged blocks to be handled specially in some sort of way, since that will mean having to maintain every possible way the editor may change (to get the most "fine-grained" update), when this should be a general solution.
Sorry to make you do more work here. I didn't see your comment since it was marked as resolved.
There was a problem hiding this comment.
No worries at all, that's fair. In that case, would you rather go with the original approach (i.e., only check for blocks with different indexes)?
Context
#1924
Summary
Previously, only parent changes emitted a "move" (e.g, indentations). Reordering blocks within the same parent was missed. Now, we capture each block’s sibling index and emit a "move" when either parent or index changes.
Changes
nodeUtils.ts: On top of the parent IDs, we're now keeping track of each block’s index and emitting a "move" when either parent or index changes.nodeUtils.test.ts: TODO