feat(edgeless): edgeless earser tool

[regischen]

closes #2943

[codesandbox]

This branch is running in CodeSandbox. Use the links below to review this PR faster.


  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders | Preview

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
blocksuite	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 20, 2023 0:49am
blocksuite-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 20, 2023 0:49am

[Flrande]

If we incorporate transparency into CRDT, would there be any need for an additional view layer?

[regischen]

If we incorporate transparency into CRDT, would there be any need for an additional view layer?

It's definite that transparency would be into CRDT in the future.
But in this case, I think it still needs.
because when we use eraser tool to erase element. The element be erased will show opacity. It's a state indicator instead of changing of actual opacity. It's a middle state.
And I think in the future, we still need some "middle state" in view which actually doesn't change the crdt model.
Because some interactions need to be processed in a period of time, it's not like changing fill color which is instant. we perhaps shouldn't change the CRDT's model before these interactions are completed. However, during the process of these interactions, rendering may potentially change.

[Flrande]

we still need some "middle state" in view which actually doesn't not change the crdt model.

I understand that there might be such an intermediate state, but I'm unsure if it requires adding a global code hierarchy. Would placing this intermediate state as a field within the element suffice for this purpose? My main concern is whether the view would overlap with the existing responsibilities of the surface since both essentially involve CRUD operations on whiteboard elements. Can you provide other examples where this intermediate state is necessary?

[regischen]

we still need some "middle state" in view which actually doesn't not change the crdt model.

I understand that there might be such an intermediate state, but I'm unsure if it requires adding a global code hierarchy. Would placing this intermediate state as a field within the element suffice for this purpose? My main concern is whether the view would overlap with the existing responsibilities of the surface since both essentially involve CRUD operations on whiteboard elements. Can you provide other examples where this intermediate state is necessary?

the view is not involved with crdt operations. right?
another example is

Screen.Recording.2023-06-15.at.18.25.12.mov

if in the future, we have mindmap. When we drag one child element to change it's position. I think there is a middle state.

[doodlewind]

Should wait for #3118