You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm building a #[wasm_bindgen] extension crate that needs to operate on the same LoroDoc as the JS frontend. Currently, loro-wasm::LoroDoc.doc is private, so I can't accept a &LoroDoc in my Rust crate and access the underlying LoroDocInner for operations like get_tree(), subscribe_root(), commit(), etc.
Request: Could you add a public accessor on the wasm LoroDoc struct? Something like:
This would allow extension crates to depend on loro-wasm via git and build into a single WASM module that shares the same LoroDoc instance with JS — no dual-doc bridging needed.
Without this, the only options are forking loro-wasm or maintaining two separate LoroDoc instances (one in JS, one in WASM) with a sync bridge, which adds memory overhead and complexity.
I'm building a #[wasm_bindgen] extension crate that needs to operate on the same LoroDoc as the JS frontend. Currently, loro-wasm::LoroDoc.doc is private, so I can't accept a &LoroDoc in my Rust crate and access the underlying LoroDocInner for operations like get_tree(), subscribe_root(), commit(), etc.
Request: Could you add a public accessor on the wasm LoroDoc struct? Something like:
impl LoroDoc {
pub fn doc(&self) -> &LoroDocInner {
&self.doc
}
}
This would allow extension crates to depend on loro-wasm via git and build into a single WASM module that shares the same LoroDoc instance with JS — no dual-doc bridging needed.
Without this, the only options are forking loro-wasm or maintaining two separate LoroDoc instances (one in JS, one in WASM) with a sync bridge, which adds memory overhead and complexity.