Y.Doc instances have properties isSynced and isLoaded - but to my current understanding, these properties are always false.
y-websocket has a property synced and an event callback on('sync',...) which can be used to determine the current sync status of the associated Y.Doc
But y-indexeddb has on('synced',...) only
Thus:
well, why are two different event names used?
how can I determine the current database sync status of a Y.Doc?
is it guaranteed that there is no race condition between const Persistence = new IndexeddbPersistence(...) and Persistence.on('synced',...) such that I just have to wait for the synced event?
will this event by fired again after every change (deeply) within the Y.Doc as soon as that change is persisted?
I think it was just an oversight in the API design. YJS providers are fairly eclectic.
There is no race condition if you call persistence.on('synced') immediately after instantiation, since synchronous code executes without interruption. i.e. It is guaranteed that your event handler will be set up before synced can fire.
You can also use await persistence.whenSynced, which resolves the first time the synced event fires and is instantiated in the constructor.
No, and unfortunately y-indexeddb does not fire an event when the update has been successfully saved to the database. I guess it is assumed that there will always be a connection to IndexedDB. Since storing updates is not throttled, all updates up to the last few hundred milliseconds should be persisted to the database in an unexpected power failure.
If you have to have confirmation that the update has been persisted to the database, you could fork y-indexeddb and emit an event from this._storeUpdate:
That is strange. It should, as that’s definitely where updates are stored.
I would double check that the edited dependency is being included at all. It depends on your build process. For example, some build processes will use js and some will use cjs, so make sure to run npm run dist in your fork.