Collaborative list

A shared to-do list, held as a BcrdtArray whose elements are each a BcrdtMap with a title and a done flag. Two independent replicas of the document demo-list are shown; add, rename, tick and reorder in either one.

Two replicas of one list

Add an item in either replica, rename it, tick it, move it up or down - and watch the other follow.

Opening two replicas…

Worth trying. Take Replica B offline. In A, rename an item. In B, tick the same item and add a new one. Bring B back: the rename and the tick both survive on the same item, and B's new item is now in A as well. Then try the reorder arrows on both replicas while one is offline. Moving an item removes it and inserts a copy of it at the new position, so two people moving the same item concurrently can produce two copies of it, and a rename or tick made concurrently with somebody else's move of that item is lost, because it lands on the element the move removed. Those are genuine limitations of the operation rather than bugs, and they are called out in the library's own documentation for Move.

Why a list of maps

The nesting is the point. If each item were stored as a single string or a serialized blob, then one person renaming an item while another ticks it would be two writes of the same value, and one of them would have to lose. Because an item is a real collaborative map, the rename touches the title key and the tick touches the done key, they never contend, and both survive. Two people editing the same key of the same item still resolves last-writer-wins - the merge is per key, not per keystroke.

Ordering is handled by the sequence itself. Concurrent insertions at the same position are placed in an order every replica independently agrees on, and a run inserted by one person stays contiguous rather than interleaving with a run inserted by someone else. Concurrent deletion of the same item is idempotent: it disappears once and never comes back.

Edit this page on GitHub