true if the handle is in one of the given states.
true if the document has been marked as deleted.
true if the document has not been deleted.
Repo only hands out handles that already have data, so this is true
from construction unless delete() is called.
true if the document is currently unavailable.
true if the document has been unloaded.
InternalNumber of handles with at least one listener attached.
InternalNumber of nodes in the per-document handle trie. For tests.
Snapshot of this handle's segments with their currently-resolved
prop values (key string / literal index / matched index). Fresh
per call; empty on the root.
The cursor range for this handle, if any.
This handle's URL.
The URL might include a path, or heads, both optionally.
like this: automerge:<docId>[/path][#heads];
InternalUsed by DocSynchronizer to deliver inbound ephemerals.
Sends an arbitrary ephemeral message out to all reachable peers who would receive sync messages from you. It has no guarantee of delivery, and is not persisted to the underlying automerge doc in any way. Messages will have a sending PeerId but this is not a useful user identifier (a user could have multiple tabs open and would appear as multiple PeerIds). Every message source must have a unique PeerId.
All changes to an Automerge document should be made through this method. Inside the callback, the document should be treated as mutable: all edits will be recorded using a Proxy and translated into operations as part of a single recorded "change".
Note that assignment via ES6 spread operators will result in replacing the object
instead of mutating it which will prevent clean merges. This may be what you want, but
doc.foo = { ...doc.foo, bar: "baz" } is not equivalent to doc.foo.bar = "baz".
Local changes will be stored (by the StorageSubsystem) and synchronized (by the DocSynchronizer) to any peers you are sharing it with.
On sub-handles a non-function callback is shorthand for "replace
the value at this path" (e.g. counterSub.change(42)). Function-typed
values can't use this shorthand - wrap them in () => yourFunction.
A function callback's return value is ignored (the document is mutated in place), consistent with root and sub-handles alike - so an accidental arrow-expression return won't replace a scoped object. Use the shorthand form to intentionally overwrite a slot.
Optionaloptions: Automerge.ChangeOptions<T>True if this handle's path is a strict ancestor of other's path,
within the same document and view (heads).
Marks the document deleted and fans delete out to every retained
handle (root and subs alike). Calling on a sub-handle deletes the
whole document; use DocHandle.remove to remove a subtree.
Prefer Repo.delete from user code.
Emit an event on this handle. Routed through the registry's
listener storage. Fires only this handle's listeners; use
delete() to fan out the document-level lifecycle events.
True if the other handle has the same URL as this one.
Names of events with at least one listener attached.
Returns the latest known heads for the given peer's storageId, or undefined if we have not received sync info from that peer.
Use DocHandle.getSyncInfo instead. Will be removed in the next major.
Returns the "heads" of the document, akin to a git commit. This precisely defines the state of a document.
the current document's heads (which may be fixed by .view() or equivalent)
Returns an array of all past "heads" for the document in topological order.
UrlHeads[] - The individual heads for every change in the document. Each item is a tagged string[1].
A point-in-time in an automerge document is an array of heads since there may be concurrent edits. This API just returns a topologically sorted history of all edits so every previous entry will be (in some sense) before later ones, but the set of all possible history views would be quite large under concurrency (every thing in each branch against each other). There might be a clever way to think about this, but we haven't found it yet, so for now at least we present a single traversable view which excludes concurrency.
Check if the document can be change()ed. Currently, documents can be edited unless we are viewing a particular point in time.
boolean indicating whether changes are possible
Number of listeners attached for the given event.
Snapshot of currently-registered listener functions for the given event.
Merges another document into this document. Any peers we are sharing changes with will be notified of the changes resulting from the merge.
the merged document.
Optionalfn: DocHandleEvents<T>[E]True if this and other are both text-range handles on the same path
whose ranges overlap in the current document.
Returns [startIndex, endIndex] for this handle's cursor range,
resolved against the handle's own view of the document, or
undefined if this handle has no range.
Called by the repo to reuse an unloaded handle.
Remove the value at this sub-handle's path from the underlying document.
Optionalfn: DocHandleEvents<T>[E]ExperimentalCreate a sub-handle scoped to a location inside this document.
Returns the same DocHandle instance for the same path, ensuring referential equality via the per-document registry trie.
This API is experimental and may change in future versions.
Called by the repo to free memory used by the document.
Returns a promise that resolves when the handle is in one of the given
states (default ["ready"]).
OptionalawaitStates: HandleState[]
A DocHandle is a wrapper around an Automerge document. It allows you to read and change the document, as well as to subscribe to changes.
DocHandles are created by the Repo class, generally through repo.find() or repo.create().
A simple DocHandle is defined by a URL with only a documentId, but it is also possible (via the URL) to specify a specific version via "heads", or to scope the handle to a subtree of the full document with a path.
Conceptually a handle is just
(document, path, range?, heads?):Repoonly ever hands out root handles.Handle identity is canonicalised by the per-document registry, so any two calls that name the same
(path, range, heads)triple - even via different traversals - return the sameDocHandleinstance.To modify the underlying document use either DocHandle.change or DocHandle.changeAt. These methods will notify the
Repothat some change has occured and theRepohandles persisting to your local storage as well as propagating changes to connected peers.