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.
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.