Relative Positions

[jclem]

Currently, the only way to store a position in a SharedString appears to be by inserting a Marker in the positions where the comment range begins and ends. However, Markers are not ideal for storing positions which are not part of the document content.

For example, I want to implement comment ranges on top of a SharedString in CodeMirror, but in order to do so, I have to use Markers to represent comment ranges, and then map them to decorations in CodeMirror. This is quite tricky, because decorations in CodeMirror are not part of the document content. This means that in order to map edits from CodeMirror to my SharedString, I have to map those edits against all Markers in the document that affect the edit.

Another difficult thing to deal with when using Markers for comment ranges is the fact that Markers are deleted when they lie within a range removed by functions like removeText. Instead, for a comment implementation to work, I would need those Markers to remain in place even if they lie within a range of removed text.

Is there anything similar to relative positions from Yjs in Fluid that I'm missing? A Yjs relative position is just a value stored outside of the shared string type whose absolute position automatically slides as changes occur around it.

Update Some additional context: I've also spoken with folks working on Automerge, who are going to incorporate the Peritext CRDT there. Peritext markers (which are useful for commenting, but also things like rich text implementation) will work similarly to relative positions in Yjs, in that they are built to preserve user intent. This means that removing a range of content which includes some marker will not just remove that marker/boundary and invalidate the document. Instead, it'll preserve its relative position after the edit has been applied.

[tylerbutler]

@anthony-murphy @Abe27342 Do you have any thoughts here?

[Abe27342]

Thanks for the ping @tylerbutler --I do :).

One major question:

This is quite tricky, because decorations in CodeMirror are not part of the document content.

Are these decorations not collaborative or persisted cross-session at all? or am I misunderstanding something about the use case?

If they are truly some transient state that needs to only exist locally, I'd recommend using local references. This is what we're currently recommending people use to power their undo-redo stack, for example.

If you do need some kind of persistence in the document model, I'd recommend using the interval collection API. You can associate intervals to a range of characters on your SharedString. When the string is modified, the interval will behave as you expect; similarly to the behavior you'd get by adding transparent markers to that SharedString, but without the drawbacks of the marker being removed on deletion of a range including the interval's endpoints. You can effectively store arbitrary data on the interval by adding properties to it (including handles to other DDSes if you need rich merge semantics on that data).

The semantics of how the interval behaves aren't particularly customizable right now: an interval endpoint lying on a range of text that's deleted will always attempt to "slide forwards" if possible, then "slide backwards" if not, but the out-of-the-box behavior sounds like it may be good enough to suit your needs. Happy to clarify any questions you have.

[jclem]

The decorations are collaborative and persisted cross-session, yeah. It's just that markers are insufficient because they're part of the SharedString model.

Thanks a ton for this reply: It sounds like interval collections will work. I had somehow completely missed them in the Fluid docs, but I now see them here.