Important: if you plan to use Yjs in a "no-build environment" (i.e., without using a module bundler such as webpack or Rollup), please import from my Yjs bundle in order to avoid a serious Yjs issue!
The Y.UndoManager
only tracks operations on a single Y.Doc
. Previously, you needed to maintain several undo managers if you had several documents. With the introduction of subdocuments, we now have documents nested inside each other and it often makes sense to have only a single undo/redo history for the document collection.
YMultiDocUndoManager
is an UndoManager that enables you to track operations on a collection of documents. It implements the same API as Y.UndoManager
and can safely be used in editor bindings that accept an existing Y.UndoManager
as a parameter.
import { YMultiDocUndoManager } from 'y-utility/y-multidoc-undomanager'
const ydoc1 = new Y.Doc()
const ymap1 = ydoc1.getMap('my-map')
const ydoc2 = new Y.Doc()
const yarray2 = ydoc1.getArray('my-array')
// either specify tracked types at the beginning
const um = new YMultiDocUndoManager([ymap])
// or add them dynamically
um.addToScope([yarray2])
ymap1.set('a', 1)
yarray2.insert(0, ['a'])
um.undo() // yarray.toArray() ⇒ []
um.undo() // ymap.toJSON() ⇒ {}
Y.Map doesn't make use of Yjs' optimizations if you write key-value entries in alternating order. Always writing the same entry does't significantly increase the size of the document. But writing key1, then key2, then key1, then key2 (alternating order) breaks Yjs' optimization. YKeyValue implements a more efficient key-value store that allows frequently updating alternating entries. Y.Map needs to retain all key values that were created in history to resolve potential conflicts. This makes Y.Map unsuitable as a key-value store. Using this implementation, the size of your document will shrink significantly when deleting keys.
import * as Y from 'yjs'
import { YKeyValue } from 'y-utility/y-keyvalue'
const ydoc = new Y.Doc()
const yarr = ydoc.getArray()
const ykv = new YKeyValue(yarr)
// Fires events similarly to Y.Map when content changes
ykv.on('change', changes => {
console.log(changes)
// => Map<string,
// { action: 'delete', oldValue: T } |
// { action: 'update', oldValue: T, newValue: T } |
// { action: 'add', newValue: T }
// >
})
ykv.set('key1', 'val1')
ykv.set('key1', 'updated')
ykv.delete('key1')
ykv.set('key1', 'new val')
ykv.get('key1') // => 'new val'
Nota bene:
YKeyValue
is not another "shared type" (likeYArray
orYMap
), but an implementation on top ofYArray
npm test
The benchmarking suite operates on N different keys. We generate X set operations on the keys.
The benchmarks show that Y.Map
creates documents that depend on the number of operations created. While YKeyValue
's size only depends on the size of the map.
We measure the size of the Y.Doc
using the different approaches (Y.Map
vs YKeyValue
).
operations | keys | YKeyValue doc size (bytes) |
Y.Map doc size (bytes) |
JSON size (bytes) |
---|---|---|---|---|
100k | 10 | 271 | 524985 | 121 |
100k | 100 | 2817 | 578231 | 1291 |
100k | 1000 | 30017 | 593834 | 13891 |
500k | 10 | 329 | 2684482 | 131 |
500k | 100 | 3013 | 2954249 | 1391 |
500k | 1000 | 31005 | 2992244 | 14891 |
We call yarray.toArray()
every time something changes. This does make key-value store unsuitable for huge collections (>1 million objects). Furthermore, the benchmarks take quite some time. However, each operation individually still takes less than 1 millisecond when operating on datasets with less than 1 million objects.
We can work directly with Yjs' Item
objects without calling yarray.toArray()
every time something changes. This requires us to expose some internal features of Yjs which I don't want to do until the Move feature lands in Yjs.