Offer "full serialization" and "minimal serialization" for events

[ex0ns]

While trying to save the undostack to make it persistent, I noticed that move event are not serialized correctly, indeed, oldParentId and oldCoordinate are not saved into the JSON, I don't know if it's the expected behaviour, but it seems pretty strange:

It can be reproduced easily, first move a block into the workspace, then run the following code, and undo the last event, it will throw an error (Cannot read property 'nextConnection' of null).

const save = Blockly.mainWorkspace.undoStack_.map(function(event) { return event.toJson(); });
Blockly.mainWorkspace.clearUndo();

Blockly.mainWorkspace.undoStack_ = save.map(function(event) {
    return Blockly.Events.fromJson(event, Blockly.mainWorkspace);
}

If this is indeed a bug, I could submit the fix I wrote for my app.

ex0ns

[rachel-fenichel]

Hi @ex0ns,

I can explain why this behaviour exists, and then we can figure out what to do about it.

The assumption was that serializing events was for sending to a real-time collaborator or something similar. We did not intend for editor B to be able to undo work done by editor A. (For instance, Google Docs lets you undo your own work but not other people's work.) So we expected each editor to keep its own undo stack in the session, based on recent events done in that session.

The serialized events are being kept as small as possible, since they will be sent across the wire.

One option may be to let the developer choose between "full" and "minimal" serialized events.

Please describe your use case so we can figure out what the best solution is.

[ex0ns]

I see, seems pretty logical. I needed this "full event serialization" to make the undostack persistent accross many reload of the editor. In order to achieve this, I serialize them, send them to a server (or localstorage) and when the editor is reloaded the undostack is re-created from those paste event.

To handle the multi-user scenario, I simply attach the session/user to each save of the undo stack I do and restore only if the session/user matches.

[rachel-fenichel]

@NeilFraser do you have thoughts on this? We've heard from a few developers now that they want to be able to use the JSON serialization to save event stacks, for replay or for persisting undo/redo across sessions.

@ex0ns I've updated the issue name to reflect the feature request I see here.

[NeilFraser]

Everything from everyone on this comment thread is completely correct. I have nothing insightful to add. :)

[maribethb]

Can we create a plugin that serializes the undo stack as part of the workspace data? That would fulfill this particular request without having to offer separate system for "full" serializing events. If so, let's move this to a feature request in blockly-samples.

[BeksOmega]

Can we create a plugin that serializes the undo stack as part of the workspace data?

There's currently not a great way to do this, because we don't give people direct access to the undo stack. If getUndoStack and getRedoStack were public, we could /serialize/ but there's still no good way to /deserialize/. For deserialization (with the current APIs), we could construct every event, and fire it (and undo it for the redo stack case) but that's pretty inelegant imo.