Expose inner LoroDoc reference from loro-wasm::LoroDoc for extension crates
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- rust, wasm
- Domain
- api, developer-experience
Research direction
Start at the loro-wasm::LoroDoc definition and inspect how its private doc field wraps the underlying LoroDocInner. Add the requested public accessor and verify that an extension crate can use it to call operations such as get_tree(), subscribe_root(), and commit() on the shared document.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Rust
- Stars
- 6.1k
- Forks
- 178
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 22
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from loro-dev/loro
-
Difficulty 3/5 1-2 days Newbie friendliness 82/100
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100