Save and Apply/Reuse History

I was wondering what is the best way to go about saving the history?

Is there a way to serialise the history from https://prosemirror.net/docs/ref/#history and then reuse it ?

The idea is that I could save the doc someone is working on and all of it’s history with it to the database (JSON and/or HTML) and reinstate it when needed. Call it as a “snapshot” of the document at the time.

Although I am not sure how useful this would be in real life just playing with the idea.

Any thoughts ?

The history plugin could define an external format for history data and expose a toJSON method that serializes it and a fromJSON method that deserializes. You could then use State.toJSON to save a state including its history data.

But this hasn’t been a convincing enough use case so far for anybody to work on it.

Yes. Having thought about it I am not convinced it wouldn’t be all that useful for me either. At first it seemed like a good idea but I can just store the state or the html in my case and this is good enough for now.

I guess if I was using PM collab features than in scenario when two people work on the same document it could be a nice way of seeing what the other person has done / edited out. Perhaps highlighting the bit of document they worked on. If that is even possible …

@marijn What’s the current state of this feature? Was it ever implemented? We are currently preserving the history in our backend together with our auto-save data so that in case of a browser refresh, or even in case of resuming an editing session from a different computer, the user can maintain their undo history, but we do it by tracking the steps and replaying the history on load which is not efficient. If the feature doesn’t exist, any risk at adding a toJSON and an optional history plugin json init argument to set its initial state? (I don’t mind creating a PR if this has a chance of being accepted as a feature)

This hasn’t been implemented, but I’d be interested in such a PR. I think the main complication would be that SelectionBookmark isn’t currently serializable, and would have to be made so, which would be a breaking change, since people can subclass it. But we could handle that by implementing serialization for the bookmarks in the library, and making the history serialization code drop selections that don’t have a toJSON method.

This seems really interesting and useful.