Feat: Scope cut-copy-paste

[li-xin-yi]

1. Add cut/copy button for scopeNodes. Behave like the cut-copy-paste feature of codeNodes.
2. Rewrite the cut logics, reuse the implementation of pasting and simplify the code. Generalize the cut-copy-paste behaviors for both codes and scopes.
3. Extend the internal node to several set/list of nodes, prepare for the implementation of multi-selected node cut-copy-paste in the future.

Other miscellaneous:

1. Fix the bug that delete button of rich text node doesn't work

To-do:

1. Code clean-up.
2. Performance enhancement.

[li-xin-yi]

Update:

1. Improve insertion speed by using prisma.createMany
2. Fix the black border issue inside the pane when canceling the pasting via Esc: manage the pane focus/blur state by zustand store, only paste pods when the pane is focused. Besides, it also regards the click on copy buttons as a click on pane, so you can immediately paste pods after copying.
3. Fix the right-click menu icon color issue, make it always consist with the text color on hover.
4. Clean up the code and add some comments.

I feel it ready for merging, but there are still some potential directions for further optimization if we have time:

For performance:

1. updateView contains too many operations, which is heavy to run every time any change occurs. We may introduce some light update functions for different categories of changes, like tempUpdateView in this PR only update the position of the top-level pasting nodes. We can divide updateView to several different functions to reduce unnecessary overall update.
2. xPos and yPos change force the re-rendering of nodes (notice they are parameters for React.Memo hook), so it takes a lot of time to re-render a bunch of nodes even when moving only one node. I don't realize where the two parameters are consumed except in debug mode. We can use getNode to get the position info only when necessary in order to release the space and time to memorize it.

For code:

1. Pasting and cutting are really similar, we can further reuse the code, when cut begins also set pasting and checking if it is cutting when pasting ends.
2. Apply Eta reductions for many functions that has only one line to invoke other functions, don't wrap too many functions with different names with too many layers.

Known issues:

1. Sometimes the node in yjs is deleted slower than the deletion in store, which raises a warning as: [WARN] CodePod rendering pod not found
2. Even though the prisma.create/createMany is async, it can't promise the record(s) inserted into DB when the function returns a result, there is a short delay, sometimes it may be longer. So we may update a pod that even not in the DB sometimes.

But they are not big deals, 1) they rarely happen, I just came across a few times and I can't reproduce them now because of the strict conditions 2). I add many try/catch clauses to handle them to protect the whole update process from blocking. I list them here just in case you come across them and let you know the bugs are introduced in this PR.

[lihebi]

One bug: after copying a scope, the nodes inside the scope can be moved out. The reason is that the extent: "parent" field is not set for the new scope.

For reference, this extent: "parent" field is set when a pod is moved into a scope.

codepod/ui/src/lib/store/canvasSlice.tsx

Lines 608 to 617 in 5b39efe

	let newNode: Node = {
	...node,
	position,
	parentNode: scope.id,
	extent: "parent",
	data: {
	...node.data,
	level: scope.data.level + 1,
	},
	};

[lihebi]

fixed

[li-xin-yi]

I see. This may be the same reason why a pod can be moved out after refreshing the page. Let me take a look and fix the bug tonight.

[lihebi]

fixed

@li-xin-yi

[lihebi]

For performance:

Yeah, the performance for coping a scope wasn't good. The scope is jumping with the cursor instead of moving smoothly.

2. xPos and yPos change force the re-rendering of nodes ... re-render a bunch of nodes even when moving only one node ...

I feel this wasn't the issue. Re-rendering all nodes is always necessary for a single node change because there's no way to update one single node in ReactFlow. So the root problem is that ReactFlow models the nodes as a list, not a hashmap. We'd probably have to drop Reactflow in the long run.

[lihebi]

I'll leave a few days for me to debug the performance. Then let's get this merged.

[li-xin-yi]

Update: I added one line to fix the bug that a pod can be moved out of scope after refreshing the web page. If you want to test it, please restart the socket docker first.

But it may be better to check the extent field before every time call setNodes to update nodes, which make sure the pod is always restricted in its parent. I don't know if the check is necessary.

[lihebi]

I’ve fixed it as well.. in case you missed my commit.

[li-xin-yi]

Not the same bug, I fixed the one for refreshing.

[lihebi]

I see. Sounds good.

[lihebi]

Merging. Let's fix the performance later. Thanks, Xinyi!