Subdocuments in ws-provider

There are a few attempts to make subdocuments sync over the ws-provider:

It’s been two years since those discussions though.

Is there anything new to say? I’m presuming that ws-provider won’t get official subdoc support any time soon?

It seems to be a harder problem that I’d expect? I’m not sure why the special protocol for syncing is needed when the regular docs don’t use it?

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.

1 Like

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.

1 Like

Ok, thank you for your insights.

I ended up refactoring and not using subdocs, but just plain documents that are loosely coupled by name.

1 Like