Currently, EphemeralStore exposes the following API for inserting values into the store:
set(key, value)
apply(bytes)
There is no convenient way to process incoming data before applying it to the store. For example, a subscriber may need to deserialize a payload, extract specific fields, validate, or transform the data before passing it to EphemeralStore. Currently, apply(bytes) only accepts raw bytes, which prevents consumers from handling structured data before it reaches the store.
The current workaround is to parse the data manually and use set(key, value). However, this has unintended side effects: set() treats the update as a local mutation and triggers local update event listeners, even though the data originated from a remote peer.
Maybe I am missing something obvious?
My proposal would be to either make the origin explicit:
set(key, value, from: "local" | "import")
or allow apply() to accept non byte values.
As context I noticed this when trying to use the https://github.com/loro-dev/loro-prosemirror CursorEphemeralStore. Specifically I did not want to send the user field to my custom endpoints as the current user is derived via its socket id and user information/styling lives in another castle.
Currently,
EphemeralStoreexposes the following API for inserting values into the store:There is no convenient way to process incoming data before applying it to the store. For example, a subscriber may need to deserialize a payload, extract specific fields, validate, or transform the data before passing it to
EphemeralStore. Currently,apply(bytes)only accepts raw bytes, which prevents consumers from handling structured data before it reaches the store.The current workaround is to parse the data manually and use
set(key, value). However, this has unintended side effects:set()treats the update as a local mutation and triggers local update event listeners, even though the data originated from a remote peer.Maybe I am missing something obvious?
My proposal would be to either make the origin explicit:
or allow
apply()to accept non byte values.As context I noticed this when trying to use the https://github.com/loro-dev/loro-prosemirror
CursorEphemeralStore. Specifically I did not want to send theuserfield to my custom endpoints as the current user is derived via its socket id and user information/styling lives in another castle.