i dont know what’s going wrong but it’s just getting slower and the website lost response sometimes.
does anyone meet the same issue?
How big is your Doc?
Y.encodeStateAsUpdate(doc).length
god , i glance over the other post knowing 2 means empty (from you), and i set a 10s delay ,here supposed to be the right size
it seems the doc is very big ,is there a good way to solve this problem?
Yes, that’s good to confirm that the problem is with the size of the Doc.
Doc size grows in proportion to the number of edits, so the best way to mitigate this is to throttle edits and consider putting high volume changes in Awareness which can resolve conflicts in real-time but does not keep its history. It will depend on your specific use case and the expected user behavior. I’m not sure what your data model is or how often you are currently committing changes.
I do have several high volume changes like cursor position change and I use a y.Map type to store the data , everytime the position change , the code run
window.ymapPos.set(userA, currentPos) ,
I used to think the previous data is just repalced, but by the way if it’s pushed into a history stack, where can i find it ?
Cursor position should probably be stored in Awareness rather than the Doc itself, and possibly persisted outside YJS if conflicts are not an issue.
There is no easy way to view the history of edits in a human-readable form. They are stored in a compressed format structured around causality. The raw data is in doc.store.
Personally I wish there was better support for managing document growth, such as visibility into the Doc store and safe ways to drop or compress history. Many Docs never get to this point, but when one does, it’s pretty bad. There is nothing that really exists right now to prevent perpetual increase of load time.
1 Like
Yes, I agree with you. But is the history just used for Y.UndoManager ? And now that all historical records are preserved, is there no limit to the undo times?
And if I want to achieve some effect like reappear historical user operation , is that possible to use that history data ?
The history is not just used by the UndoManager, but is core to how CRDTs work. It specifies the causal relationships between edits that allow conflicts to be resolved automatically.
It is possible to display and recover specific history states for user features using the snapshot API. Unfortunately it’s not very well documented, but there are some old posts that cover it.
1 Like
That’s very clear, thank you very much !!
1 Like