Errors after hooking up flyout events to VM about scratch-vm HOT 5 CLOSED

aahhh!

When blocks are dragged from the flyout, a new CREATE event is generated for them - with a different workspaceId. But then, a DELETE event is fired for the old block in the flyout - which has the same block ID, but a different workspaceId.

Our implementation doesn't consider workspaceId because I assumed the blocks in the flyout would have unique IDs vs. the blocks in the workspace. Not sure why this didn't become a problem in the prototype. Probably a good way to solve this would be just track workspaceId on the block representation as well, e.g., blocks[workspaceId][blockId] = {...}. Any thoughts, @thisandagain ?

from scratch-vm.

Oh, actually we never saw this in the prototype because flyout blocks were never created/destroyed after the first display of the flyout. This is only really a problem with category switches.

from scratch-vm.

Yikes. Tracking the workspace ID along with the block seems like a reasonable way to deal with it. This and #46 might be nice to talk about today.

from scratch-vm.

Other options include:

• Modify Blockly to generate a new unique ID for blocks when they're dragged from the flyout to the workspace.
• Tack on workspace ID to block ID in the VM representation (e.g., "workspaceId:blockId") and make sure to parse this correctly as it's going in and out.

from scratch-vm.

We've fixed the problem in scratch-blocks by ensuring blocks always have a unique ID.

from scratch-vm.