hocuspocus does not explicitly support subdocuments, but they added multiplexing this Spring which provides efficient syncing of many documents over a single websocket connection. I currently use a custom module that manages loading and destroying documents as needed.
The hocuspocus community is more active, too. Sad to see the core YJS libraries stagnate.
Hocuspocus is indeed nicer (the database abstraction is very useful), but I’m not sure how I can add subdocument support.
Hocuspocus sends documents to the database layer as update dumps, so the subdocument information is lost I think?
Do you have any ideas?
In this case, I do know what I’m storing and what subdocuments are supposed to be in there, so I can change the loaded document to have them, but I suppose they won’t get tracked for updates.
When you store a subdoc in a shared type, it saves the guid of the subdoc in the update. It will be persisted with the update. This is true with any provider, not just Hocuspocus.
const root = new Y.Doc()
const folder = root.getMap()
const subDoc = new Y.Doc()
subDoc.getText().insert(0, 'some initial content')
folder.set('my-document.txt', subDoc)
In the above example, the folder Map will store the subDoc guid in my-document.txt.
If you think of it as a graph, we would say that the “edges” to subdocuments are stored in the document. As long as the document and subdocument are independently persisted to the database, the subdoc will not be lost. The thing you have to do manually is to check if a document has subdocs, and then initiate loading them from the persistence layer. However, multiplexing documents over a single websocket connection has to be implemented in the provider’s networking layer.
Personally, I find the subdocument support to be so thin that it’s hardly worth it. I manually manage a tree of subdocuments using an append-only log of guids from documents that are updated. This allows me finer control over lazy loading and replication of the full tree.