marks with rich attributes

[jjallaire]

Noted the discussion about Automerge marks having a name and primitive value whereas Prosemirror marks can have arbitrary JS objects as attributes. The comments example illustrates how to store the richer attributes out of band and refer to them with an ID. However, I'm wondering if given the prevalence of extended attributes on marks (e.g. many markdown flavors including Pandoc allow attaching an id, classes, and keyvalue pairs to marks; links can have both an href and title, etc.) that richer storage should be supported in mark.value? There may be a good reason not to do this, just wanted to raise it as a possibility.

I am currently working around this by serializing mark attributes to JSON before setting into value (and reversing this on read). However, it seems like for the highest fidelity merging you would want to be able to read and write individual properties (one author might change the id whereas another adds a class, etc.).

[alexjg]

@orionz, @pvh, @ept and I have spent a bunch of time trying to figure out a nice approach to this. After much discussion we've landed on allowing any Automerge value to be the value of a mark (i.e including maps and lists), but that value will be immutable (cannot be modified by subsequent changes, instead updates to the mark will create a new object). This avoids a number of extremely weird edge cases when merging concurrent updates to a mark object. I'm hoping to write this up a bit more soon.

To support this we'll be introducing the concept of an "atomic object" to Automerge. Atomic objects are immutable composite values. These may also be useful for representing other immutable values like coordinates in a penstroke.

Until we have a nice immutable object API serialising to JSON makes sense.

[jjallaire]

Thanks, very glad to hear that this is in the works!